Les recettes de John Swenson sur les réseaux

[gillou 45]

(08-14-2018, 11:04 PM)r11bordo a écrit : Celui là est pas mal ! https://jcat.eu/product/m12-switch-gold/

Ouais mais là, autant changer de serveur

[a supprimer merci]

Je pense qu'une des raison pour lesquelles on perçoit tous différemment les modifications opérées sur les source (et dont font partie les "tweaks" réseau) sont que les DAC utilisés sont plus ou moins sensibles à ces variations. John Swenson a bien résumé la situation dans un "post" daté de 2013 que j'avais repris ici: http://forum-hifi.fr/thread-5709-post-16...#pid162761

Bonne lecture..

[r11bordo]

Dans ce cas, il n'y a pas que les dac qui sont sensibles, les fda aussi. je n'ai pas de dac, je passe du drive reseau au fda directement et là aussi c'est bien sensible.

[gillou 45]

(08-15-2018, 10:15 AM)r11bordo a écrit : Dans ce cas, il n'y a pas que les dac qui sont sensibles, les fda aussi. je n'ai pas de dac, je passe du drive reseau au fda directement et là aussi c'est bien sensible.

 Pour moi egalement. Le plus bel upgrade etait le Waversa mais trop cher pour moi. Et le m1 est un fda avec drive integré

[a supprimer merci]

(08-15-2018, 10:22 AM)gillou 45 a écrit :

(08-15-2018, 10:15 AM)r11bordo a écrit : Dans ce cas, il n'y a pas que les dac qui sont sensibles, les fda aussi. je n'ai pas de dac, je passe du drive reseau au fda directement et là aussi c'est bien sensible.

 Pour moi egalement. Le plus bel upgrade etait le Waversa mais trop cher pour moi. Et le m1 est un fda

Les principes sont les mêmes. La phrase clé dans le lien cité, et qui s'applique à (presque) tout signal qui rentre dans les DAC ou FDA (même combat) :

"High frequency ground noise is extremly pernicious stuff, it will find a way to get around just about any obstacle you throw in its path."

Hormis la fibre optique point de salut... 

Le point suivant mis en avant par Swenson est intéressant et peut expliquer pourquoi certains entendent des différences liés à certains changements et pas d'autres:

"Different designers take different approaches to try and achieve this with varying degrees of success. The different approaches will usually be affective at decreasing susceptibility to different types of noise so one DAC model may not care about a certain aspect (say cable differences) while another may be pretty immune to cable aspects but be susceptible to timing variations in packets. This may be a part of why some people say they can hear certain aspects and others say they cannot. "

[Le dom]

(08-14-2018, 06:28 PM)Nicoben a écrit : @ Le Dom, de mon coté je n’officie que sur des renderer intégrés du commerce (refstream, Trinnov Amethyst) qui par définition ne sont pas optimisables et ne font pas appel à une liaison usb en sortie rendant peut etre plus dépendants l’un de l’autre le dac et le renderer que dans le cadre d’une liaison spdif plus prévisible coté résultats, plus limitée cela dit...

De l’autre je ne fais aucune optimisation serveur (minimserver sur nas ou pc, upnp) et demande donc au renderer de faire le résultat audio seul, et en arrive à la conclusion que pour ce genre de cas, c’est au dernier élément du réseau , un routeur ou équivalent, d’assumer la totalité des non optimisation en amont (box, alims, serveur...) par une de pollution et reclockage réseau.

Dans ton cas, pour moi, en mode bridge, j’aurais tendance à penser que la meilleure optimisation de base serait de coller une Jcat éthernet avec alim linéaire dans le renderer, ainsi on remplit le rôle d’un switch audiophile placé entre les deux, bien plus efficacement (moins de cable, pas de passage par une carte éthernet basique sur le renderer.
Un appareil comme le Waversa peut offrir en un seul appareil l’optimisation de la liaison ethernet du bridge, et le reclocking de la sortie usb du renderer (mais tu fais déjà j’imagine un travail sur la sortie usb du renderer?), ainsi que l’alim de l’ensemble sur batterie, c’est une option qui peut se tenir... mais qui met une bonne part du résultat sonore dans le même panier, pas dans la logique d’un gars qui aime maitriser chaque centimètre de la restitution du serveur au dac...non je me trompe? c’est le choix de Franz en comparaison.

Possible aussi de pousser le concept du bridge comme conseillé par Jplay, une Jcat dans le serveur et une dans le renderer. 800 balles quand même sans alim... ça donne envie de se poser la question du meilleur reclocking usb en sortie de renderer, n’aurait il pas plus d’impact et retour sur investissement que pousser l’optimisation de la liaison ethernet du bridge? C’est le software des plateformes informatiques qui optimise le mieux le bridge je suppose dans ton cas, tu t’emmerdes avec ça depuis un moment, ls jcat doivent surement simplifier cette optimisation, mais ton optimisation dont Pascal dit qu’il faut plus rien toucher, plaide plutot pour tirer le max du reclocking de la sortie usb (meilleur appareil, meilleure horloge et alim, meilleur cable usb....). Je dis ça mais ne sait pas ce qu’il y a entre ton renderer et ton dac.... carte usb sotm dans l’ordi, reclocking externe usb vers usb, rien?

Ma réflexion à vide du soir, qu’en dis tu?

Cordialement, Nico.

Oui j'en suis à ce stade de réflexion.
Ma config était décrite de manière assez précise dans ma signature mais certains se sont plaints de sa longueur... 

Le PC audio renderer RoonBridge Endpoint est un PC sous windows Server 2016 core edition + Audiophile Optimizer + Fidelizer 8.2 + Jplay 6.2. De plus les ports USB classiques sont désactivés sur la carte mère et le DAC est relié à ce PC par un combo SOtM sCLK48.0 - tx-USBexp de chez SOtM.
En ce qui concerne le résultat obtenu à l'heure actuelle, lire les derniers CR de Pascal64.

Mais bon, mon cas étant un cas à part... Je n'insisterai pas sur ce point.

[Nicoben]

(08-14-2018, 11:27 PM)blutbad a écrit : Demain je reçois mon filtre ethernet Sotm. Je vais faire des essais . Audio et vidéo .

Version de base, ou avec circuit d’horloge sCLK-EX intégré? Avec ou sans l’alim SPS500? C’est plein d’options Sotm, et comme Roberto l’a dit à juste titre pour le SMS200, l’alim est plus importante que l’upgrade d’horloge, est ce le cas aussi ici vu que la base est vendue avec une alim de supermaché?...

Bons essais ! 

@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. »

Cordialement, Nico.

---

(08-15-2018, 10:15 AM)r11bordo a écrit : Dans ce cas, il n'y a pas que les dac qui sont sensibles, les fda aussi. je n'ai pas de dac, je passe du drive reseau au fda directement et là aussi c'est bien sensible.

Un FDA est un dac ! Un « dac de puissance » qui convertit le pcm en pwm qui est modulé sur les enceintes, avec gestion d’horloge, bruit, jitter, distorsions... ces soucis sont possiblement plus vite discernables sur un FDA de par son coté direct, et moins qualitatif coté alim et circuits numériques pour les petits, que de gros dacs mieux fichus... simple supposition

@Phile. eeee le coup des passage d’alim dans les cables éthernet, ça semble tout de même revenir au « simple » fait que les cables ont toujours une influence sur le courant qu’ils transportent, un cable est toujours à la fois une sorte de filtre, de micro, d’antenne... on bricole on bricole mais cela n’évitera pas le fait que nos alim à découpage de base, nos powerbank, nos émetteurs récepteurs de pont optique... contiennent toujours des sources de pollutions dont l’impact varie dès qu’on modifie légèrement quelque aspect que ce soit dans l’alimentation, le cablage donc une forme de filtrage de l’alim. A mon avis les bricolages d’optimisations diy quels qu’ils soient ont l’avantage d’améliorer le résultat final par une approche empirique rapide du sujet, mais ils n’ont le plus souvent aucune étude sérieuse au cul permettant de dire qu’on a résolu le problème, c’est pour cela qu’à un moment on est rattrappé par des solutions commerciales qui si elles ont le défaut de leur coût destiné à faire vivre des gens, ont l’avantage d’aller potentiellement plus au fond du problème pour le limiter dans des proportions plus importantes, avec une meilleure maitrise.

Cordialement, Nico.

[KIKIWILLYBEE]

Bonjour ,
et bon week-end à tous,

SVP, à propos du bruit de phase des horloges, il faut se reporter à la variance de allan :
https://en.wikipedia.org/wiki/Allan_variance
L'analogie pourrait être hydraulique, et comparer la distribution du temps à celle d'une conduite d'eau forcée.
La precision à long terme, inutile dans nos applications serait l'écoulement stable du liquide en fin de colonne.
La precision à court terme, celle à l'entrée de la colonne, la ou les contraintes physiques sont les pus importantes,
et le trouble d'écoulement du liquide le plus contraint. Ce 'bruit' est sur l'écoulement +/- stable du liquide : le temps .
De même il faut distinguer jitter électronique, et jitter informatique..., et ne pas mélanger les bruits ...(svp... ).
(mais bien sûr les bruits électroniques perturberont le bon fonctionnement des horloges qui nécessitent un environnement physique (température,stabilite mécanique), et électronique (stabilité, absence d'interférences ds le courant) stable et dénué de pollutions hf...)....
https://fr.wikipedia.org/wiki/Gigue_(électronique)
https://fr.wikipedia.org/wiki/Gigue_(informatique)

....
Bien à vous,
cdlt,
w :-).

[Pascal64]

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.

[r11bordo]

Ce qui m'a frappé dans mes essais autour du switch, c'est de retrouver la signature sonore de la ifi ipower en branchant cette dernière sur mon switch DLink ...
De mon point de vue, il y a clairement une corrélation entre l'alimentation utilisée et le courant électrique servant au transport de données dans les câbles réseaux. Pour la partie clock, je n'ai rien testé.