Les switchs audiophiles + ponts optiques

[rastabill]

Bonjour Baldoun, As tu un lien ou ils ont effectués des modif sur l'alimentation et autres ?

[Baldoun]

Bonjour Rastabill,
n'étant pas bricoleur, je n'ai jamais regardé les tweaks sur le 2960. Mais j'ai été un moment intéressé par le Catalyst (avant d'avoir l'etherregen) et j'avais notamment consulté le forum Naim en ce sens : https://community.naimaudio.com/search?q=2960 et le lien vers le topic spécifique des switchs : https://community.naimaudio.com/t/ethern...mania/4385 avec quelques photos de l'intérieur du Catalyst.
Je me rappelle que certains lui avaient changer le fusible et passer sur alim linéaire mais comme ce n'était pas le but de ma recherche, j'ai dû en oublier. 

Sébastien

[rastabill]

Merci beaucoup c'est exactement ce que je cherchais 

[hug!]

Tiens j’en ai un! 24 prises! J’essayerai ça plus tard, là je pars quelques jours!

[phile]

Hello,
je ne sais si ce point à été abordé quelque part, surement sur ce sujet... (mais relire autant de pages, bof bof...)

Le nombre d'appareil "accessoires réseaux" "hifi" est en plein essor on dirait depuis qq temps mais il va croissant fortement, et le nombre de sujets liés idem (cf ce sujet).

Il y a un bail j'avais installé un réseau optique en sus du pont optique (les 2 tjs en fonctionnement). On focalisait à l'époque sur les EMI qui forcément ne passent pas via la fibre. C'était déjà ça...

Les protocoles (terme techno, mais ne suis pas spé, donc me corriger si incorrect) utilisés en démat réseau c'est UPNP/DLNA principalement (Airplay parfois mais je ne connais pas donc n'en cause pas), Roon est différent mais ne sait s'il répond à cette problématique...
Quand on pense réseau on pense transit via tcp/ip.
J'avais bien lu il y a un bail la page wiki sur UPNP disant que c'est de l'UDP. Ca m'avait fait tilté mais j'ai ensuite zappé ce point...

Bref,
tous ces switches audiophiles et autres accessoires réseaux qui induisent un mieux que le rendu, c'est à cause de l'UDP, non ?

En audio, pas de tcp/ip, mais de l'UDP donc pas de contrôle que l'info envoyée est bien arrivée au streamer.
Bref, problémtique streaming réseau = problémtique streaming USB : la source (PC/serveur) balance la sauce, le streamer (interface / USB) reçoit ce qui lui arrive, en sort de la musique.
Et les pertes entre la source & le streamer/interface... sont perdues.

Donc en gros, faut passer tous nos accessoires réseaux à la mouture "hifi" (alims propres, horloges de concours sur switches, etc) ?!

Si un spé du sujet pouvait confirmer ou infirmer les idées vagues & maladroitement décrites dans ce post, ce serait sympa. Merci.

Et désolé si j'enfonce une porte ouverte depuis lgtps. 1er post sur ce sujet à la page 378... je crois que j'ai qq trains de retard... 
Cdt

[r11bordo]

euh ... tcp, udp, point de rapports j'aurais envie de dire ... Sur les systèmes le permettant, il suffit d'augmenter quelques buffers réseaux pour faire travailler les streamers en mémoire plus qu'en accès réseau pour y voir effet notable sur la restitution. C'est un peu transformer sont appareil en marque UP Design ou un truc du genre, cf le topic fermé des appareils sans connectiques réseaux sur lesquels il fallait charger ses pistes à la mimine avant d'écouter la variation de pression d'air:-)

[Nard]

Citation :En audio, pas de tcp/ip, mais de l'UDP donc pas de contrôle que l'info envoyée est bien arrivée au streamer.
Bref, problémtique streaming réseau = problémtique streaming USB : la source (PC/serveur) balance la sauce, le streamer (interface / USB) reçoit ce qui lui arrive, en sort de la musique.
Et les pertes entre la source & le streamer/interface... sont perdues.

Que je sache c'est TCP/IP qui est utilisé, au moins sur le Wan pour le streaming, et il n'y a aucune perte. En local avec UPNP je suis moins certain mais sois sûr que s'il y avait des pertes cela s'entendrait

[LittleScarabee]

@Phile -

Pour moi ce qui impact sur le rendu sonore c'est :
1 / La qualité du réseau en lui même : soit on sait et on arrive à implementer un réseau dédiée pour la partie Audio (VLAN specifique en d'autres termes) et par conséquent tu isoles un point qui génére je pense beaucoup de perturbations c'est le "broadcast" issu du routeur essentiellement et des autres équipement du réseau. Tu as une option sur certaines équipements réseaux qui permettent d'éviter cela (fonctionnalité de : Storm Control)

2 / La qualité des composants installés dans nos switchs

3 / Concernant le protocole utilisé retenu par l'application.... ce sujet a été cadré dans des hautes sphères de prendre de l'UDP à la place du TCP... je serais tenté de dire "dont acte"  : il doit y avoir une bonne raison à tout ça ! Après pour pallier à ça et si le swtich le permet peut être que la solution c'est de faire de la QoS sur ton réseau après avoir analyser les ports source et destination + protocoles utilisés !? 

Je ne rentre pas dans le débat de l'alimentation qui joue son rôle aussi, j'ai volontairement fait le focus sur le switch et ces fonctionnalités : mais c'est important on est d'accord. Idéalement lorsque l'on aura accès facilement à des cartes réseaux fibre on pourra aller plus loin, mais c'est un autre sujet et peut être qu'il ressortira dans quelques années seulement pour s'affranchir du cuivre.

Pour revenir à ta remarque sur l'UDP : j'utilise JPLAY et MinimServer et dans mon analyse du traffic j'ai identifié qu'il faut prioriser les ports suivants (TCP à 100% dans mon cas) :

[phile]

(05-19-2020, 12:12 PM)Nard a écrit : Que je sache c'est TCP/IP qui est utilisé, au moins sur le Wan pour le streaming, et il n'y a aucune perte.

ce n'est pas ce que dit la littérature que j'ai trouvé hier soir 
En effet, c'est assez compréhensible : tcp/ip sous-entend "contrôle que ce qui est envoyé est arrivé", donc de facto, tu as un flux double :
1. de l'emetteur vers récepteur : l'envoi
2. du récepteur vers l'metteur : renvoi, afin que l'emtteur contrôle et valide que le récepteur a bien tout reçu.
Dans le tome 54 des oeuvres de je ne plus qui que j'ai lu hier il fait la remarque que le streaming video (nul doute que c'est idem pour l'audio) utilise l'UDP car en tcp/ip ce flux double surchargerait le système. Dans les fait, l'UDP marche très bien. Pour schématiser, il y a des coupure parfois... pas grave... et hop le récepteur retrouve le flux et hop le film continue à la tv, 2-3 pixelisations sur 4-5images... pas grave car l'oeil n'y a rien vu...

@ Littlescarabee : +1
1/ => je vais regarder ça, merci pour l'info
2/ => effectivement, c'est sans aucun doute LE sujet qui nous concerne. udp etc, compte sans doute pour des ppm dans l'histoire.
3/ question à 2 balles : sur ton switch si tu change tcp en udp, ca s'entend ?
Cdt

[LittleScarabee]

(05-19-2020, 01:27 PM)phile a écrit : 1/ => je vais regarder ça, merci pour l'info

@Balboun nous a partagé un sujet très intéressant il y a quelques jours (cf. sujet ici) que j'ai rapidement lu et "Simon-In-Suffolk" (cf. post ici) l'explique encore ici le point de vue que je te partage (après je comprends que ce n'est pas simple à mettre en place).

En complément tu peux regarder la solution pfSense (remonté par @bbill) ; pour ma part je compte utiliser cette solution prochainement pour gérer mon réseau. C'est une solution gratuite de base donc à toi de voir après : achat d'un boitier tout fait ou te monter toi même la solution.

(05-19-2020, 01:27 PM)phile a écrit : 3/ question à 2 balles : sur ton switch si tu change tcp en udp, ca s'entend ?  
Cdt

Je ne me suis pas amusé à faire ce test. Si je change cela : je vais m'opposer au principe de base de communication identifiée par ces deux applications. 
Comme on est sur la couche de "transport", je ne souhaite pas toucher à tout ça dans le sens où une application est identifiée pour fonctionner sur un protocole et un port donné ! Le seul levier pour moi est de "jouer" sur le niveau de priorité de tel ou tel ports via la QoS (car le "traffic" réseau est tellement dense qu'en définissant une priorité on améliore un peut les chose). Sujet QoS soulevé par @bbill

Maintenant si tu créés un VLAN spécifique pour ta Hifi j'ai un très gros doute sur la nécessité d'appliquer de la QoS. Sur les Meraki pour ceux qui ont une licence (même temporaire, car normalement il va chercher sa configuration qu'après un full reset) ils peuvent déjà limiter le broadcast en activant la fonctionnalité de filtrage par adresse Mac sur le port du Serveur Hifi en autorisant qu'une liste prédéfinie d'équipements autorisés à communiquer avec ce dernier