Wireshark - Analyseur réseau au secours de votre SQ

[Steph44200]

Sujet dédié créé

[floyer]

ces latences et autres sont sans doute corrigées par un bon switch ? une horloge ?

Il y a deux choses : la latence et la gigue. La latence est le temps que mettent les paquets pour aller de l'émetteur à destination. Tant qu’elle est constante, cela n'a pas d'influence sur la qualité (en caricaturant, si l'album date de quelques années, quelques millisecondes de plus ne changeront pas grand chose).

La gigue est en revanche un point sur lequel travaille le protocole Diretta. La gigue est la variation de la latence, vu qu'elle peut varier entre chaque paquet. Là c'est plus problématique. D'une part, le target a des tampons pour absorber une certaine gigue (pour éviter des craquement lié à un paquet trop en retard), mais ce que présente Diretta est aussi de lisser le flux afin que le traitement sur le target soit homogène en terme de charge de travail, et donc de consommation électrique, ce qui évite du bruit via l'alimentation. Ce lissage est assuré par Diretta host en coordination avec le target.

Un switch est assez basique comme équipement et devrait avoir une latence constante (donc ne générera a priori pas de gigue)... sauf si au moment de la réception d'une trame, il était déjà entrain d'échanger avec le target (même avec des trames broadcast (diffusion) qui ne le vise pas directement). La solution est un switch dédié à l'échange Host-target (ou un simple câble croisé, une paire de transceiver fibre, ou que sais-je). Il peut néanmoins y avoir la différence entre les switch Full-Dupleix et Half-Dupleix (avec ces derniers, les accusés de réception Diretta ne peut avoir lieu en même temps que l'envoi d'un paquet par l'hôte). Ce qui est sûr est que le switch n'a pas l'intelligence pour corriger une gigue en amont.

A priori, la principale cause de gigue est le fonctionnement de l'OS. Il peut y avoir une horloge fixe à 1kHz, et les programmes peuvent avoir du mal à cadencer quelque chose à une horloge à une fréquence quelconque, sauf assistance d'un périphérique. Cela semble contourné par Diretta avec des modes ThredMode dit "busy-wait". Le principe est d'avoir un cœur monopolisé à attendre le bon moment (avec une précision très fine). On évite en général de faire cela (le coeur ne fair rien de productif pendant ce temps !), mais en attendant, je suppose que l'on peut se le permettre sur un Diretta-Host qui n'a pas beaucoup d'autres utilité en paralèlle. Il y a d'autres points d'architecture qui peuvent poser problème. Typiquement, sous Windows, certains traitements de driver passent par des Deferred Procedure Call qui peuvent être exclusives, et un driver graphique ou SSD par exemple peut empêcher un traitement d'un autre driver comme la carte réseau, ce qui induira de la latence et de la gigue. Cela explique l'intérêt de logiciel comme LatencyMon ou DPC Latency Checker (ils mesurent la même chose, mais présentent des synthèses différentes. En gros LatencyMon identifie le driver coupable, DPC Latency Checker affiche l'historique des traitements et leur durée, utile pour savoir si le problème est rare ou pas. Cela peut être bien d'avoir les deux). Ce problème d'architecture explique entre autre que des musiciens préfèrent des Mac pour faire de la MAO.

L'horloge ? Mes recherches indiquent que la cadence vient plutôt du target (via son DAC ou en direct, je ne sais pas). Je ne pense pas qu'il soit possible de profiter d'une horloge côté Host. (Je m'attends à ce que le protocole Diretta le synchronise). Point à vérifier.

PS : Une vision d'horreur (âme sensibles, abstenez vous) https://appuals.com/fix-high-dpc-latency-on-windows-10/ ... Ici, on a 30ms pendant lesquels, si cela se trouve, une trame Diretta pourrait être "en attente". Donc 30ms de gigue.

[Bear]

Diretta offre en effet un 'time-stamping' des trames qui sont interprétées et 'clockées' comme le souligne @floyer au niveau du target qui alimente le DAC. Si le DAC est doté d'une sortie d'horloge, le target (DDC-0 en l'occurence) peut récupérer ce signal d'horloge pour produire une synchro parfaite. Si ce n'est pas le cas, une horloge à 10MHz peut produire ce signal.

Outre cet aspect, un autre point fort de Diretta me parait être le fait que le cycle qui sert de 'fréquence d'envoi' des trames, est, si je comprends bien, auto-adaptatif. Le cycle de base est calculé en fonction de la fréquence d'échantillonnage et de la capacité du réseau (mtu). Il est ensuite adapté de façon dynamique en fonction du remplissage des buffers.

Comme on le voit sur l'exemple suivant que j'ai posté sur le fil Diretta:

Code :

./diretta_calc.py --analyze-sync 1000
====================================================================================================
DIRETTA STABILITY ANALYSIS (LAST 1,000 LOG ENTRIES)
====================================================================================================
Service: diretta_sync_host
Generated: 2025-11-03 23:03:33
Analyzing logs...
✓ Logs captured. Performing analysis.

1. NETWORK TIMING JITTER (from 'cy=...' values)
----------------------------------------------------------------------------------------------------
  Assessment:        ✓ Good (IQR < 5μs)
  Samples found:      1,000
  Average Cycle:      2932.308 μs
  Standard Deviation: 4.885 μs  <- (primary indicator of stability)
  Interquartile Range (IQR): 4.296 μs  <- (robust jitter measurement)
  Min / Max Cycle:    2917.784 μs / 2945.710 μs
  Peak-to-Peak Range: 27.927 μs
----------------------------------------------------------------------------------------------------

on peut aussi évaluer en regardant les logs produits la façon dont ce cycle évolue dans le temps et confirmer si les conditions du réseau sont propices ou non.

[KIKIWILLYBEE]

Bonjour les Gars .’!,

Svp ,
Revenant , sur mon precedent avis vs. L’excellente économique de l’introduction d’une tentative de ´bonnes pratiques’ pour une infrastructure 8o2.3 Audio SQ. , et sans revenir sur la définition du NETWORK JITTER. , je vais vous présenter ci dessous un moyen de trouver des métriques comparatives et objectives ´ de test et comparaison pour nous permettre de débattre et développer sur le potentiel du ( infrastructure de référence vs.) -> TL‑WR902AC. ( ou autre XX.)

Soit donc svp.,
Objectifs : capturer et comparer le même flux RTP. ou audio. réseau dans deux topologies et comparer le jitter calculé par Wireshark. selon la formule RFC 3550.(formule standard)…

I.- Montages à comparer.

• Topologie A (référence) : serveur/streamer. → switch/routeur. principal stable (gigabit.) → endpoint audio. (STREAMER.).

Vs.

• Topologie B (avec .’pocket‑router.’.!)  : serveur/streamer → TL‑WR902AC. Ou XX. (en routeur ou point d’accès Wi‑Fi) → endpoint audio.

Il.- Capture Wireshark.
• Lancer la capture sur l’interface du endpoint. ou sur un .’port. mirroring.’ du switch, dans chaque topologie, avec le même fichier/flux. à joué en boucle.

• Filtrer le flux. (par ex. `rtp.` ou filtres IP./por. spécifiques au streamer.). Wireshark. sait identifier les flux RTP. et leur appliquer ses propres stats dédiées.

III.- Analyse du jitter dans Wireshark.
• Menu « Telephony → RTP. → RTP.Streams », sélectionner le flux audio., clic. « Analyze. » : nous obtiendrons svp. pour chaque stream le jitter moyen et max. , pour un graphe de ‘.jitter en fonction du temps.’ et les pertes/retards de paquets.

• Dans la topologie A. notons typiquement un jitter moyen faible !. et un graphe relativement plat (variations lentes et modestes -> NETWORK JITTER ., stabilité de la variation de la latence
• Dans la topologie B.XX. avec le TL‑WR902AC. Alias XX. ; constat probable..??? —> ‘des pointes de jitter plus élevées, davantage de fluctuations et parfois des pertes/retards ou même lag.’s (a remarqués dans la fenêtre RTP. comme « lost. » ou « late. »).

IV.- Graphiques complémentaires
• Toujours dans l’analyse RTP. Nous afficherons le « Jitter Graph. » qui devrait tager clairement les oscillations. et pics. de jitter.  ou variations de la latence encore : ce graphe sera alors l’illustration comparative et résumera ( de facto. je n’ai pas de routeur de poche , dsl., pour réaliser les métriques comparatives -> (courbe bleue. « routeur. ‘ principal. »vs., courbe rouge. « TL‑WR902AC. ou XX. »)

Que faut il en conclure svp. ?, avez vous des avis ?, et est-ce important ou nécessaire de s’orienter sur ces questions ?

Vous remerciant,
Vous souhaitant un bon week-end.,
Cordialement.,
W. ;-).

[Lapinou]

Salut Willy,

merci à toi d'échanger sur la question des réseaux. Ceci étant, il me semble que la question du bon fonctionnement d'un réseau local dans le cadre de la musique dématérialisée reste bien loin de ce que tu évoques ici avec un analyseur de trames, pour de nombreuses raisons.

J'ai résumé ça en "NB" de mon post sur les signaux numériques : le débit d'un réseau local est tellement supérieur à ce qui est nécessaire pour la musique qu'il n'y a pas de question à se poser. Si le dysfonctionnement du réseau est tel que l'écoute de musique est impactée, alors d'autres symptômes seront visibles bien avant (usages informatiques, télévision), et il ne sera pas nécessaire de recourir à Wireshark. En outre, lorsqu'il s'agit de streaming, l'origine du flux se trouve à l'autre bout du pays / du continent / du monde. Pour arriver jusqu'à ton réseau local, les données auront traversé quantités de réseaux sur lesquels tu n'as aucun contrôle, et qui sont soumis à des contraintes autrement plus larges (c'est à dire perte de paquets bien plus courante, latences très supérieures et gigue extrêmement variable). Disposer d'un réseau local cadencé à la picoseconde n'empêchera pas qu'à l'extérieur, c'est le far west.

Quoi qu'il en soit, il n'en demeure pas moins que la bonne mise en oeuvre de son réseau local est primordiale pour la dématérialisation (et ça ne concerne pas que cet usage), mais il s'agit bien plus de réfléchir aux chemins de câbles, aux cascades de switchs et à l'isolation du tout que de recourir à un analyseur de trames (et même à d'autres outils bien plus adaptés à la métrologie).

Fondamentalement, les réseaux informatiques sont aujourd'hui conçus pour des usages bien plus sensibles que la haute fidélité, et... on peut leur faire confiance pour assumer !

Si Yu Harada, par exemple, a inventé Diretta, ça n'est pas pour remettre en cause le fonctionnement des réseaux pour la hifi, mais pour réduire le bruit généré par l'activité du processeur.

Bonne démat sur des réseaux simples et sains !

[KIKIWILLYBEE]

Bonjour,

Et Merci beaucoup pour ta réponse entropique ,
Je comprends parfaitement ton point de vue , et aussi comment peuvent apparaître mes interventions , et pour cela acceptes mes excuses pour mes maladresses ;
néanmoins l’exemple de DIRETTA. que tu cites , n’illustre t il pas a contrario qu’un travail local sur le L2. est immédiatement audible , pourquoi pas un tronc.Ip.sur le L3.? , j’exposerai aussi le cas typique de la Voip. (Ou AES.67.) et de sa sensibilité à l’infrastructure ?.
Mais, je tiens à te rassurer sur ma démarche , je ne suis pas un obsessionnel des métriques ou de la complexité , mais il est surtout agit de tenter de comprendre , puis de dégager et expliquer des ‘Bonnes Pratiques.’ Utiles et les points clefs à mettre en avant pour un exemple d’infrastructure idéale à partager pour un .’flux SQ.’ au moins Ambitieux ..
….
Courtoisement,
Willy ;-).

[floyer]

Pourrais-tu décrire un « tronc » IP ?

Je pense que l’idée est d’utiliser directement le protocole de plus bas niveau pour éliminer tous des traitements dont on maitrise peu l’impact sur la gigue. A priori, le protocole IP fait toujours la même chose (avec une table de routage qui ne bouge pas, des options d’entête constants, etc), mais je ne sais pas comment les accès à la couche IP par Diretta et les autres flux interfèrent.

[KIKIWILLYBEE]

Koukou…

Stp . ,
En résumé
Un .’tronc. IP.’ au sens TRUNk. 8o2.1Q. (IEEE.) ou agrégation de liens sert à transporter plusieurs VLAN. (réseau logique ) et/ou à agréger plusieurs liens physiques en un seul lien logique, ce qui permet de mieux isoler, prioriser et fiabiliser ls flux SQ. mais plutôt of course dans une infra. 8o2.3 un peu ambitieuse. ( a envisager dans la catégorie mise au point tweak.’s réseau extrême après tout le reste ….)

l’intérêt d’un tronc IP. dans un flux SQ. :
est architectural : celà permet de structurer le réseau pour isoler, prioriser et ou fiabiliser l’audio, plutôt que de s’en remettre à un câblage .´ à plat.’ où tout le traffic confus se superposera…..

Exemple concret : un lien TRUNK. entre
a-1.routeur principal et un b-1switch dans le salon transporte VLAN_AUDIO (endpoint, streamer.)
et b-2VLAN_DATA (TV, box, PC),

mais avec une mise en place de la QoS. (Qualité de service.) qui protège spécifiquement le VLAN_AUDIO des ´bursts.’ Ou Pollutions des autres usages.

Trunk 8o2.1Q. : un port qui transporte simultanément plusieurs VLAN.’s tagués (Voix, Data, domotique, etc.) entre deux équipements (switch–switch, switch–routeur, switch–serveur).

Accessoirement aussi , stp.,
l’Agrégation de liens : LAG / LACP. Soit trunk: plusieurs liens physiques sur ton Switch pour doubler ou isoler : ex. 2×1 Gb/s ou 2x2.5 Gbs-1.(soit 5.o Gbs-1.) vus alors comme une seule interface logique et augmenter bande passante BW. ou assurer la redondance de liens et répartition isolation des flux.

Enfin la
Priorisation : chaque VLAN. ou classe de traffic peut recevoir une QoS. spécifique DSCP/8o2.1p (on parle aussi de QoS. Différentielle ) celà qui permet de donner une priorité haute à l’audio vs le reste du trafffic.
Il est possible d’alller au delà encore dans le tag. et la priorisation spécifique des flux…

Le trunk IP. ne nettoiera pas le jitter de l’horloge audio, mais il aidera certainement à contenir le jitter réseau et la variabilité de latence induits par la congestion, les mauvaises priorités et les collisions entre services non spécifiques, cependant on peut donc avancer une stabilisation des variations de latence et une minimisation effective du NETWORK JITTER..

Ainsi,
En séparant les VLAN.’s et en tagant correctement nos flux audio. , nous contraignons les variations de file d’attente dans les switches/routeur, donc les spikes de latence et de jitter réseau.
Donc En ayant des trunks bien dimensionnés entre les nœuds critiques (NAS/serveur, cœur de réseau, baie audio), nous devrions éloigner que la plupart d’autres usages saturent le même lien physique que celui dédié à notre précieux chemin Audio. Enfin, réaliser un design. de la.infra. .Vec un chemin phy. audio isolé de tout autre flux sur une priorité propre élevée ou critique associée à une Qos,diff.

https://www.formip.com/pages/blog/trunk/
https://community.fs.com/fr/article/vlan...avoir.html
https://en.wikipedia.org/wiki/Trunking
https://fr.wikipedia.org/wiki/R%C3%A9seau_local_virtuel
https://liora.io/vlan-tout-savoir
https://www.dmi40.fr/comprendre-les-vlans/
https://en.wikipedia.org/wiki/Quality_of_service
https://en.wikipedia.org/wiki/Quality_of_service
https://www.nrmagazine.com/comprendre-la...sentielle/
..
Cordialement,
W ;-).

[floyer]

Je connaissais le Trunk IEEE 802.1q… mais c’est pas au niveau IP. J’imagine que si l’on sollicite Linux pour envoyer des trames Ethernet sur un VLAN sur une interface eth0.10 par exemple, elle profitera des caractéristiques de cette interface et notamment le champ PCP qui porte la priorité… mais de mes recherches, il faut utiliser « tc qdisc » pour associer au champ PCP une priorité d’émission. Bref, c’est pas encore très net pour moi, mais deux interfaces réseaux dont une dédiée à Diretta me semble le plus simple. Les VLAN avec trunking me semblent utiles pour gagner une interface sur l’hôte Diretta. Mais cela complique les choses. De plus, il faut être sûr d’avoir un switch compatible IEEE 802.1q et 802.1p.

[Olivier]

Je ne suis pas persuadé que cela puisse être utile dans le cadre d'un réseau domestique. L'utilisation de VLAN peut réduire le taux de broadcast et donc une activité réseau "presque" inutile. L'application d'une QoS en VOIP est utile, bien qu'aujourd'hui, sur un réseau "dense" d'entreprise, on privilégie un "Voice VLAN" dédié SIP. Or, notre usage est très différent (hors Diretta entre host et client, RAAT, et NAA). Pour amener une réflexion: débranchez le cable réseau du streamer en cours de lecture, et observez le résultat, ensuite faite de même sur un téléphone SIP (non POE) en cours de communication, et comparer. Je rajoute le flux duplex nécessaire à la VOIP, pour se couper la gueule !
L'étude comparative de la latence et de la gigue entre un réseau filaire et un wifi, ne nécessite pas WireShark !