Le Forum Indépendant de la Hifi et des Audiophiles

Mise à jour du post 1 avec le nouveau kit de base de cable rj45 de Rastabill : http://forum-hifi.fr/thread-33503.html

Merci Denis pour tes mises à jour régulières du post… 

Bonjour, pensez vous qu’un sw6 relié à une clock aune pourrait être meilleur qu’un silent angel n8’sur alim linéaire ?

(03-01-2024, 02:27 PM)Baraki a écrit : [ -> ]pensez vous qu’un sw6 relié à une clock aune

pas certain que ce soit une bonne idée... écoutes et mesures : lire ici
https://www.alpha-audio.net/background/a...-switches/

et notamment :
"the switch with the external clock does not measure as well. We see peaks of the clock reflected in the noise. And with the Dlink, some extra grass shows up.
....
The switch with external clock sounds a bit lighter – less rounded – but does allow transients to flow more, which is nice. It is mostly different … but thus not better in all areas we think."  (lire aussi)

c'est donc pas si simple... et la, c'est avec des mesures !

Merci bbill,

Du pour et du contre au vu de l’article.

Je n’ai pas d’alimentation linéaire sur le routeur en amont. Je pense qu’en ajouter une sera plus bénéfique que de changer de switch.

Suite à l'ajout de cette vidéo dans un autre fil, je la mets ici :

(03-05-2024, 12:39 PM)xAv73 a écrit : [ -> ]A vos claviers...

Et je me pose une question :
Au lieu de mesurer les switchs comme peut le faire ASR, est ce que ce ne serait pas plus parlant de les mesurer comme l'a fait pda0 avec différents dac sur son systeme : http://forum-hifi.fr/thread-542-post-753...#pid753090

Avec les mesures de pda0, le micro remplace nos oreilles (alors que ce n'est pas le cas d'ASR) et il mesure bien les différences dans les aigues dans son exemple. Cette différence dans les aigues est alors interprété par notre cerveau comme : "ce dac est plus sombre" ou "ce dac est plus précis", etcc....

Donc si on branchait différents switch ou non, est ce que le micro pourrait également mesurer des différences ?

Déja le micro il a une marge d'erreurs, 2 mesures sans rien toucher ne donneront même pas 2 courbes superposées a 100% (j'en ai fait l'experience avec mon MiniDSP UMIK-1 calibré).

Il est totalement impossible pour un flux informatique d'être modifié / altérée / filtré / assourdit / éclaircit / scène + large etc. etc. On manipule des 0 et des 1, à aucun moment on parle de fréquence, de plage de fréquence, de volumes, de db, de gauche droite etc etc

La seule possibilité c'est le jitter (décalage temporel du à la correction des erreurs de TCP justement), en cas de mauvais réseau ET/OU de matériel ultra bas de gamme.
Et tout les mesures sont unanimes sur l'ensemble des switch dit "audiophile" : le jitter est identique

En réseau le flux est asynchrone, et agit par buffer, le signal ne vient pas "en flux tendu", il vient pas morceaux de quelques kb voir ko (ce qu'on appelles des trames mis en buffer).

Si un DAC est impacté par autre chose que le jitter (qu'il est sensé reclocker au passage via une horloge interne), c'est qu'il est mal concus.

Bref débat sans fin ou la science et les protocoles défient les biais cognitifs et les oreilles ( qui sont des organes merveilleux, mais totalement imprécis et inapte à comparer de tel différence, dites vous que l'oreille humaine est quasi incapable de déceler 3db de différence, et incapable pour la plupart d'entendre au dessus de 13/14khz) 

Monsieur,

Svp ,
Dsl de revenir vers vous : mais révisez vos fondamentaux, il n’est pas agit de flux asynchrone, mais de flux ISOCHRONE …., c’est pour cela que ce flux est attaché a une dérive temporelle , le flux ISOCHRONE est à recurrence temporelle stricte .
Il n’y a toujours pas de correction d’erreur dans tcp , mais de.la détection de collision…. ;-) ..
Sans nous sous estimer ..,, plus aucun d’entre nous, ne fait cette confusion entre le flux. Initial Et son décodage vers la sinusoïde finale (x2 stéréo ) , sa pertinence temporelle avec l’évaluation du bruit de phase dans ce process de décodage D/A , et dans les différents flux numériques de l’ethernet. a la communication inter-chips ..

Thx. ;-).

Il y a mécaniquement une correction erreur, TCP permet d'aquitter une trame, et d'assurer qu'elle est intègre via un checksum. (et pas juste s'assurer de la non collision).

Le client redemande alors le paquet, ralentissant toute la chaine de transfert (d'où le TCP plus lent que le UDP notamment, même si c'est aussi + lent pour d'autres raison : le nombre de question / réponses entre l'émetteur et le récepteur essentiellement).


Un protocole utilisant le TCP applique forcément ce principe fondamental, si la trame n'arrive pas, ou si une trame manque (admettons il recoit la trame 1 et la 3, mais pas la 2), ou si la trame est altérée (mauvais checksum) = il redemande la trame en erreur.

Pour le reste .... c'est de l'ésotérisme, ou du matérlel deffectueux.
Il est impossible d'écouter 2 fois un système de la même manière avec la même courbe 2cm de décalage de la tête peut provoquer 6db de différences sur les fréquences.

Soit , je ne souhaite pas bousculer vos certitudes , restez-y ‘! …..mais Paquets , Trames , En-tête , segment/transport sont à distinguer par exemple (sur L2 liaison/trame L3 vs L4) , et différents entre asynchrone , synchrone et isochrone déjà …. le checksum est dans l’en-tête , pas dans le protocole : L+1. etc ..