Les recettes de John Swenson sur les réseaux

[KIKIWILLYBEE]

...."et montés sur des pointes .......".....

Yep !, perso ...ma 'super clock' à - 113 dB à 1 Hz, est sur trois pieds de sorbothane ....
SVP : Pour compléter l'explication  sur les sources de bruit sur le 'aging behavior ' des horloges :
https://www.ieee.li/pdf/viewgraphs/preci...ration.pdf
c'est la température plus que la stabilité mécanique  qui déterminera la précision ..., pour les usages militaires et embarqués,
les horloges sont durcit à la gravité, elles sont dites 'G-1'....



& pour le setting :

[Nicoben]

(08-15-2018, 01:55 PM)Pascal64 a écrit : Bien vu Willy, bientôt nous aurons tous des switchs avec de super alims linéaires ... et montés sur des pointes 

Un truc m'étonne un peu : 
Certains fabricants dont Melco - pour faire plaisir à Aredien - proposent deux ports ethernet, un pour relier au player ou DAC, l'autre pour le réseau.
Swensson se lance dans les switchs, il faut bien faire du commerce, mais pourquoi il n'y a pas plus de solutions avec deux ports ethernet sur le streamer (ou serveur) ?

Ex : Nucleus = un seul port ethernet et pas de wifi.

Le Melco est un serveur (NAS) optimisé coté alim, hardware pour moins polluer, incluant une sortie éthernet ayant le même type de vocation que les switch dont on parle ici... son résultat vient de là en fait (sortie éthernet filtrée, bien alimentée, séparée de la partie informatique et réseau en amont). Le Melco est un Nas audiophile avec switch audiophile en bref, et la montée en gamme dans les Melco permet d’avoir une sortie éthernet plus performante  Ou usb puisqu’il remplit les deux rôles soit de serveur en éthernet, soit de renderer en usb. La question est de savoir si il le fait mieux via sa solution que les fabricants de switch...ou les fabricants de renderer usb (sms200...)

Mais un fabricant de streamer n’a évidemment aucune raison de proposer deux ports éthernet, il doit juste optimiser son entrée éthernet. Donc tu réponds toi même à la question en fait, tous les fabricants de serveurs optimisés sérieux proposent une entrée réseau et une sortie réseau bien isolée de l’entrée et optimisée. Après que le renderer soit une rpi, une carte engineered, un ordi plein de xx sotm, un streamer avec dac intégré, c’est égal (sauf qu’ils ne seront pas tous si impactés par ce qui se passe en amont probablement).

Le nucleus se connecte au réseau, aucune optimisation de sa liaison éthernet, contact directe avec réseau pollué, NAS, je n’y vois aucune optimisation intéressante comme le Melco, sa seule justification est d’embarquer Roon pour jouer un role de chef d’orchestre à la place d’un nas ou ordinateur mais il fait ça en étant au milieu de la foule on dirait.

@ Willy, merci pour la lecture. Bon tu avoueras que pour savoir si oui ou non nos horloges de switch peuvent avoir le moindre influence sur le son à la fin, ça nous aide pas beaucoup, c’est plus pour la culture gérérale du coup Au mieux on pourrait dire qu’on ne voit pas en quoi l’horloge peut bien venir nous emmerder vu qu’il y a toujours du buffer derrière, puis au pire on pourrait se dire qu’il vaut mieux croire celui qui nous dira qu’il a optimisé son switch pour limiter les vibrations des connectiques, et stabiliser la température de l’horloge, cela ne le rendrait pas forcément plus crédible.
Souvent de très bons streamers ont une restitution fermée et brouillon tant qu’ils ne sont pas stabilisés en température.... des circuits de compensation existent je crois, mais pas quand le biniou est froid. Et si il consomme peu, a une inertie thermique, ça peut être long, toujours à garder à l’esprit dans les essais, que du matériel chaud...

[volpone75]

(08-15-2018, 12:07 PM)Nicoben a écrit :  
@Volpone, je suppose qu’à ce jour l’impact de l’horloge tient plus des essais empiriques réalisés par les fabricants que d’une explication logique et documentée... le monsieur de Jplay essaie de justifier basiquement son switch Jcat à plusieurs milliers d’euros par des réductions d’emi / rfi, vibrations jusqu’aux connecteurs, chassis et j’en passe, sans bien sûr donner la moindre piste sur les tenants et aboutissants des gains potentiels du dispositif...

Si je m’en tiens à ce qu’écrit John Swenson et autres moins langue de bois ou langue de marketting , il s’agit au niveau du dernier switch de se débarasser des courants de fuites (qualité d’alim, drainage), d’isoler efficacement la sortie du switch des entrées (filtres...) et pour la partie horloge d’éviter la transmission de leur bruit propre (qualité d’alim, qualité d’horloge). Le principe pour l’horloge n’est donc pas qu’elles soit plus précise pour le reclockage des données, mais que ce reclockage ne soit pas accompagné de bruit lié à la non qualité de l’horloge et ses circuits associés. 

L’on peut supposer que l’horloge la plus préce est parfois celle qui peut être la moins bruyante... donc que la meilleure en audio peut potentiellement être la meilleure sur le dernier switch... ou pas, le but est donc d’avoir le circuit d’horloge qui s’accompagne du moins de bruit possible. L’on peut imaginer dans ce cadre qu’une synchronisation entre l’horloge du switch et celle du streamer puisse abaisser le bruit lié aux horloges ou tout du moins l’impact sur le jitter en bout de chaine, d’où le choix pour plusieurs fabricants de permettre l’emploi d’une horloge maitre externe sur leur switch.... bref, comment les fabricants de switch audiophiles élaborent leur produits, empirisme, recherche, aucune idée, néanmoins ils sont un peu trop nombreux à silloner un chemin identique avec des recettes semblant se rejoindre pour qu’il n’y ait pas un intérêt autre que plumer les audiophiles crédules. Un tel raisonnement de la part du client n’est il pas cohérent pour justifier un essai, en l’absence de justifications scientifiques ?

Après de quelle manière le bruits d’une horloge de circuit éthernet aboutit  à  perturber le fonctionnement du dac, voir d’une conversion éthernet / spdif ou éthernet/i2s en terme de jitter, là est la bonne question certainement, question dont évidemment la réponse permet de sortir des produits répondant au besoin, donc dont même si elle est connue ou tout du moins maitrisée à la suite d’études ou essais empiriques, reste pour le moment la chasse gardée de ceux qui font du fric avec.... 

Si on prend les dernières déclarations de Swenson pour la mise au point du switch d’Uptone Audio, ça donne ceci: 
« As Alex mentioned I am just finishing up a complex test system for actually doing an end to end clock analysis (digital data stream to DAC output) in order to really nail down what is going on in our systems. There are several hypothesis for what is going on, and several possible schemes for suppressing these, I will be testing all of these out, and the one that works the best will go in the switch.
 
This is not JUST a development project, there is a lot of fundamental research going on. I have been doing a bunch already, enough to know that SOMETHING is going on, but not enough detail to figure out what it really is. That's what this stage of testing is all about.
 
So even if I wanted to spill the beans, I can't, we don't exactly know what beans are going to be yet!
 
The result of the above is that there is no way to speed this up, I HAVE to go through the research first before we can get to the details. We know what seats we are going to have, what the dashboard will look like, probably what tires, but not sure what engine is going to be in there. »

Merci pour ces éléments.

Cela va se décanter et s'éclaircir. On verra bien s'il y a une valeur ajoutée avérée dans ce type d'équipement et une originalité technologique par rapport aux autres dispositifs de limitation du bruit.

Sans doute aussi des mesures comparatives du genre de ce que fait souvent Archimago et peut être des écoutes contrôlées.

En parlant d'Archimago et pour les anglophones son dernier article sur les effets audibles du Jitter est intéressant: 
http://archimago.blogspot.com/2018/08/de...itter.html

On a déjâ constaté des engouements "audiophiles" unanimes qui à l'usage se délitent (pont optique, filtres ethernet, regen) ou sont gravement relativisés. L'idéal (qui reste un horizon) est pour moi un DAC résilient plutôt que de la quincaillerie périphérique.

[ttd.fornotlife]

Le T+A DAC8 DSD est il résilient ?

[volpone75]

(08-15-2018, 04:03 PM)ttd.forlife a écrit : Le T+A DAC8 DSD est il résilient ?

C'est relatif et difficile à évaluer objectivement. En ce qui concerne le Jitter en USB (la seule entrée que j'utilise) je dirais que oui mais je n'ai jamais vraiment mené de tests comparatifs sérieux en permutant des sources.

Pour le bruit je n'entends pas de bruit mais le bruit peut perturber la conversion et se manifester indirectement autrerment. Discriminer ce qui dans la qualité de rendu d'un DAC relève de la résilience aux "défauts" de la source et ce qui dépend d'autres paramètres (conversion, étages de sortie, filtrage) j'avoue que je ne sais pas faire.

Dans ma configuration, à partir de 16/44 converti en DSD en amont par HQPlayer le T+A est pour moi un "bon" DAC 1bit. Est-il particulièrement "résilient" c'est une autre histoire. En tous cas pour l'instant je n'ai pas la tentation d'upgrader ma source (ni d'ailleurs mon DAC). Le seul truc que j'aimerai pouvoir essayer est la conversion DSD512 qui est souvent vu comme le "sweep spot" de ce DAC. Pour l'instant le FW Amanero sous LINUX est limité au DSD128 et je ne suis pas très optimiste sur le fait qu'Amanero arrive à mettre au point une version DSD natif stable en 512.

[r11bordo]

(08-15-2018, 04:03 PM)ttd.forlife a écrit : Le T+A DAC8 DSD est il résilient ?

Il est Résilient Evil ... 

[ttd.fornotlife]

(08-16-2018, 08:47 AM)volpone75 a écrit :

(08-15-2018, 04:03 PM)ttd.forlife a écrit : Le T+A DAC8 DSD est il résilient ?

C'est relatif et difficile à évaluer objectivement. En ce qui concerne le Jitter en USB (la seule entrée que j'utilise) je dirais que oui mais je n'ai jamais vraiment mené de tests comparatifs sérieux en permutant des sources.

Pour le bruit je n'entends pas de bruit mais le bruit peut perturber la conversion et se manifester indirectement autrerment. Discriminer ce qui dans la qualité de rendu d'un DAC relève de la résilience aux "défauts" de la source et ce qui dépend d'autres paramètres (conversion, étages de sortie, filtrage) j'avoue que je ne sais pas faire.

Dans ma configuration, à partir de 16/44 converti en DSD en amont par HQPlayer le T+A est pour moi un "bon" DAC 1bit. Est-il particulièrement "résilient" c'est une autre histoire. En tous cas pour l'instant je n'ai pas la tentation d'upgrader ma source (ni d'ailleurs mon DAC). Le seul truc que j'aimerai pouvoir essayer est la conversion DSD512 qui est souvent vu comme le "sweep spot" de ce DAC. Pour l'instant le FW Amanero sous LINUX est limité au DSD128 et je ne suis pas très optimiste sur le fait qu'Amanero arrive à mettre au point une version DSD natif stable en 512.

Je pensai que Amanero avait regle les problemes sous linux depuis quelque temps avec une mise à jour par forcement simple sur les produits integrants l'interface.

Le probleme de la "resilience" c'est qu'il faut faire des essais pour s'en assurer chez le fabricant ou chez le possesseur du produit.

[volpone75]

(08-16-2018, 11:24 AM)ttd.forlife a écrit : Je pensai que Amanero avait regle les problemes sous linux depuis quelque temps avec une mise à jour par forcement simple sur les produits integrants l'interface.

Le probleme de la "resilience" c'est qu'il faut faire des essais pour s'en assurer chez le fabricant ou chez le possesseur du produit.

Non les problèmes ne sont toujours pas réglés sous Linux même si en ASIO sous Windows cela fonctionne parfaitement. Amanero y travaille de façon intermittente et il y a des "Beta" mais rien de stable pour l'instant.

Reste que si le T+A était vraiment résilient au bruit je n'aurais peut être pas autant de réticences à utiliser comme passerelle réseau un simple NUC Windows "bas de gamme" avec Roon Bridge. Pour l'instant j'ai pris l'option d'être limité au DSD128 avec un player Linux équipé d'une carte USB optimisée qui génère / transmet à priori moins de bruit plutôt que de franchir ce pas ... On s'éloigne des recettes de Swenson  .. quoique ?

[Joël C.]

Parce que tu en lis beaucoup de DSD 128 ?

[volpone75]

(08-16-2018, 01:17 PM)Joël C. a écrit : Parce que tu en lis beaucoup de DSD 128 ?

J'ai assez peu d'enregistrements "natifs" DSD128, surtout des Channel Classics qui sont en général excellents.

En fait j'utilise HQPlayer pour systématiquement convertir du FLAC 16/44 en DSD128 en amont et je suis très satisfait du résultat avec un DAC DSD 1bit décent. Dans cette filière je n'ai évidemment pas les bénéfices du DSD au niveau enregistrement mais en revanche la conversion en analogique est beaucoup plus fluide et le rendu bien plus agréable à mes oreilles qu'en PCM multibit.

En DSD128 cela ne demande pas énormément de puissance CPU sur le serveur, en revanche en DSD512 et si on cumule de la convolution comme je le fait il faut un CPU très "costaud". Le moteur DSP de ROON opère ça très bien mais j'ai tendance a préférer HQPlayer qui est la référence pour ce type de traitements. 

L'autre option est de faire les traitements via l'électronique interne du DAC comme le font PlayBack Design, PS AUdio, MSB et d'autres qui utilisent aussi une conversion 1bit.