Protocole Diretta

[Bear]

J'ai fait remarquer plus haut que Diretta Memory Play utilise de petits paquets UDP (par exemple, 883 octets) pour l'audio en résolution standard, même lorsque le MTU du réseau est configuré pour des trames jumbo (par exemple, 9016 octets). Cependant, lors de la diffusion d'audio haute résolution (par exemple, 352,8 kHz), la taille des paquets augmente considérablement pour remplir le MTU disponible (par exemple, 8965 octets).

J'ai demandé l'aide de Gemini de Google pour comprendre ce choix.

Ce comportement n'est pas une sous-optimisation, mais un choix de conception délibéré qui privilégie la faible latence et l'intégrité du signal plutôt que la simple efficacité de la bande passante. Le principe fondamental est la gestion de la gigue.

1. L'objectif principal : minimiser la gigue
   Pour un convertisseur numérique-analogique (DAC), la qualité audio dépend fortement d'un flux de données stable et prévisible. Les variations dans les temps d'arrivée des paquets, appelées gigue, peuvent forcer les circuits tampons et d'horloge du DAC à travailler plus fort, ce qui peut dégrader le signal analogique final.
   L'objectif principal du protocole est d'établir une transmission de paquets semblable à celle d'un métronome, avec un intervalle constant et à faible latence (par exemple, toutes les 3 à 5 millisecondes).
   
   Taille des paquets à des débits audio standard (par exemple, 44,1 kHz/16 bits)
   • Débit de données : environ 176 400 octets/seconde.[]Latence de paquetisation : temps nécessaire pour accumuler suffisamment de données audio pour remplir un paquet.[]Pour remplir une grande trame jumbo de 9 016 octets : 9 016 octets / 176 400 octets/seconde ≈ 51 ms.
   • Analyse : attendre 51 ms pour envoyer un paquet crée un flux de données « saccadé » et peu fréquent, ce qui est contraire à une conception à faible gigue. Pour maintenir un calendrier de livraison rapide et cohérent (par exemple, toutes les 5 ms), l'application envoie toutes les données qu'elle a accumulées pendant ce court laps de temps. Cela se traduit naturellement par une taille de paquet plus petite (176 400 octets/seconde * 0,005 seconde = 882 octets), ce qui correspond à l'observation.
     
   
   Taille des paquets à des débits audio haute résolution (par exemple, 352,8 kHz/32 bits)
   • Débit de données : environ 2 822 400 octets/seconde.[]Latence de paquetisation :[]Pour remplir une grande trame jumbo de 8 965 octets : 8 965 octets / 2 822 400 octets/seconde ≈ 3,2 ms.
   • Analyse : à ce débit élevé, une grande trame jumbo peut être remplie dans l'intervalle de latence faible cible. Le système peut donc maintenir son calendrier de livraison rapide et rythmé tout en tirant parti de l'efficacité du réseau offerte par les trames jumbo.
     

Le rôle essentiel du MTU et des trames jumbo
Ce protocole est conçu pour un réseau local (LAN) contrôlé. La prise en charge des trames jumbo de bout en bout est une condition préalable fonctionnelle stricte pour la lecture haute résolution.

• Fragmentation IP : le protocole UDP ne dispose pas d'un mécanisme natif permettant de découvrir le MTU du chemin. Si un datagramme UDP volumineux de 9 000 octets est envoyé sur un chemin réseau qui comprend un périphérique avec un MTU standard de 1 500 octets, ce périphérique fragmentera le datagramme en plusieurs paquets IP plus petits.[]Perte de données : le protocole UDP étant peu fiable, la perte d'un seul fragment IP en transit entraînera la suppression de l'intégralité du datagramme d'origine par le système d'exploitation du récepteur. Pour un paquet volumineux, cela signifie qu'une quantité importante de données audio est perdue, ce qui entraîne une perte audible.

Conclusion
La taille dynamique des paquets observée est une fonctionnalité, et non un défaut. Le système adapte intelligemment la taille de ses paquets en fonction du débit de données du flux audio afin d'atteindre deux objectifs distincts :

• Toujours privilégier une faible gigue : il maintient un calendrier de livraison des paquets constant et rapide, quel que soit le format audio.Optimiser l'efficacité lorsque cela est possible : il utilise des trames jumbo volumineuses et efficaces uniquement lorsque le débit de données est suffisamment élevé pour que cela n'introduise pas de latence et ne compromette pas l'objectif principal de faible gigue.

L'accent mis sur une configuration MTU appropriée vise à garantir l'intégrité du flux haute résolution en empêchant les effets catastrophiques de la fragmentation IP.

J'espère que ces informations nous aideront à comprendre certains des avantages que nous constatons lors de l'utilisation de Diretta.

[Edition]J'ai rajouté un peu de mise en forme pour aider à la lecture...

[floyer]

Il y a un point où j’ai été perdu… c’est sur la gigue… on peut avoir une faible gigue malgré une forte latence. Si tu envoies une trame toutes les heures, mais à l’heure vraiment précise, énorme latence, faible gigue.

Ma compréhension est que Diretta cherche à lisser la consommation électrique liée au traitement des paquets, et un certain rythme peut être optimal. Et pour un rythme donné, la taille des paquets dépend du débit.

[Bear]

Oui. le lissage de la consommation électrique était bien l'objectif initial Et c'est ainsi qu'ils se présentent sur leur site web.

Entre temps, il y a eu pas mal de développements allant dans le sens d'une maitrise du jitter, avec en particulier le DST-0 qui est asservi à une horloge, et qui délivre un signal de synchronisation aux composants réseau qui l'entourent, switch et carte réseau du serveur DPDK.

Le lissage de la consommation électrique n'a pas disparu, mais il est quelque peu masqué par d'autres objectifs.

L'exemple que tu prends me parait mal adapté au sujet traité. En audio, nous savons que ce n'est pas la précision d'une horloge qui compte, mais son absence de dérive dans le temps.

Il me parait intéressant de regarder ce sujet de trames UDP, qui, contrairement à des trames IP, peuvent se perdre. Du coup, la régularité de leur acheminement fait sens.

As-tu une meilleure interprétation à proposer ?

[jean-luc]

Salut Pierre,

et merci pour ce partage toujours aussi précis et passionnant. Tes retours sur Diretta et la gestion des trames UDP sont particulièrement éclairants, surtout quand on creuse le sujet de l’Alan Deviation — un point qui, je pense, mérite d’être souligné pour bien comprendre les choix techniques de Diretta.

1. Alan Deviation et la régularité des trames
Tu as raison de rappeler que la gigue ne se résume pas à la latence, mais bien à la stabilité temporelle du flux de données. L’Alan Deviation (ou déviation d’Allan, pour les puristes) est une mesure clé de la stabilité d’une horloge sur le moyen terme. Dans le contexte audio, cela signifie que même si un paquet arrive avec une latence élevée, ce qui compte, c’est que l’intervalle entre les paquets soit constant — comme un métronome parfait.
Diretta, en adaptant dynamiquement la taille des paquets, cherche précisément à minimiser les variations de timing (donc l’Alan Deviation) plutôt qu’à optimiser la bande passante. C’est une approche qui fait sens :

• En basse résolution (44.1 kHz/16 bits) : des paquets de ~883 octets permettent d’envoyer des données toutes les 5 ms, ce qui est bien plus régulier qu’attendre 50 ms pour remplir une trame jumbo. La gigue est ainsi réduite, car le DAC reçoit un flux continu et prévisible.
  
• En haute résolution (352.8 kHz/32 bits) : le débit est tel que même une trame jumbo est remplie en 3-4 ms, ce qui permet de concilier efficacité réseau et régularité.
  
  

C’est une optimisation intelligente : Diretta privilégie la stabilité du flux (et donc la qualité sonore) à l’efficacité brute. Et c’est là que le DST-0 entre en jeu, avec son asservissement à une horloge externe, pour verrouiller la synchronisation du réseau et limiter les dérives.

2. Pourquoi pas toujours des trames jumbo ?
Floyer, ta remarque sur la latence vs. gigue est pertinente, mais il faut ajouter un paramètre : la fragmentation. En UDP, si un paquet jumbo est fragmenté (parce qu’un switch du chemin a un MTU inférieur), la perte d’un seul fragment entraîne la perte de tout le paquet. En audio haute résolution, cela se traduit par des craquements ou des interruptions, bien plus gênants qu’une légère gigue.
Diretta évite ce risque en :

• Utilisant des petits paquets en basse résolution : moins de données perdues en cas de problème, et une régularité optimale.
  
• Passant en jumbo en haute résolution : quand le débit le permet, et que le réseau est configuré pour (MTU cohérent de bout en bout).
  

C’est un compromis pragmatique, pas une limitation.

3. Lissage de la consommation vs. maîtrise de la gigue
Tu as raison, Bear, de souligner que le lissage de la consommation électrique était l’objectif initial. Mais aujourd’hui, avec le DST-0 et son horloge maître, Diretta va plus loin : le réseau devient un prolongement du DAC, avec une synchronisation quasi-parfaite. La régularité des trames UDP n’est plus seulement une question d’économie d’énergie, mais bien de fidélité du signal.
Pour reprendre ton exemple, Floyer : envoyer une trame toutes les heures avec une précision atomique donnerait une gigue faible, mais une latence inacceptable en audio. L’enjeu est de trouver un rythme optimal (quelques ms) qui concilie :

• Faible gigue (intervalle constant entre paquets),
  
• Faible latence (réactivité),
  
• Robustesse (pas de fragmentation).
  
  

4. Et l’Alan Deviation dans tout ça ?
C’est là que ça devient passionnant. L’Alan Deviation mesure la stabilité à moyen terme d’une horloge. En audio, une horloge avec une faible déviation d’Allan garantit que le DAC ne va pas "dériver" au fil des minutes, ce qui évite les distorsions de phase ou les artéfacts temporels.
Avec le DST-0 et son horloge asservie, Diretta verrouille la synchronisation du réseau, réduisant ainsi l’Alan Deviation à un niveau quasi-nul. Résultat : un flux audio d’une stabilité exceptionnelle, même sur des sessions longues.

En résumé :

• Diretta adapte la taille des paquets pour minimiser la gigue, pas pour optimiser le réseau.
  
• Les trames jumbo sont utilisées quand c’est sûr (haute résolution + MTU cohérent).
  
• L’Alan Deviation est maîtrisée grâce à l’horloge du DST-0, ce qui explique la qualité sonore observée.
  
• Le compromis est intelligent : régularité > efficacité brute.
  

Pierre, tes essais montrent bien que Diretta n’est pas qu’une solution "simpliste", mais une approche systémique où chaque détail compte. Et Floyer, ta question sur la gigue vs. latence est cruciale : en audio, la régularité prime sur la vitesse pure.

Pour aller plus loin :

• As-tu testé l’impact d’un switch dédié (type LHY ou Cisco optimisé) sur la stabilité des trames jumbo, Bear ?
  
• Floyer, qu’en penses-tu de l’idée d’utiliser un analyser de gigue (comme un Audio Precision) pour mesurer l’Alan Deviation en sortie du DST-0 ?
  

[Bear]

@Floyer: pour préciser: les mesures que j'ai faites et la configuration sur la base de laquelle j'ai travaillé avec l'IA est la configuration particulière que je possède. Elle ne reflète pas la majorité des configurations Diretta bien entendu. Ce serait peut-être intéressant que d'autres fassent des mesures s'ils en ont l'élan

@Jean-Luc: le réseau 'très local' sur lequel fonctionne l'ensemble les composants Diretta (serveur DPDK et DST-0) s'appuyait sur un switch piloté par le DST-0 et donc l'horloge à 10MHz. Mais il n'est pas possible à ma connaissance de faire des mesures à cet endroit. Les mesures que j'ai faites sont sur la carte réseau de mon serveur distant.

J'ai entre temps, et à la faveur de la découverte de la possibilité de rajouter la 2ème carte réseau au DST-0, connecté le serveur DPDK directement à cette deuxième carte réseau ; on ne passe donc plus par un switch. La connexion entre serveur DPDK et DST-0 est configurée avec un MTU de 16'128. La carte réseau de base du DST-0 ne sert que pour les mises à jour, et pour le fonctionnement en syncAlsa dont j'ai mesuré qu'il ne bénéficiait pas des Jumbo Frames.

---

J'ai longuement évoqué la notion de 'Sweet-spot' à 8fs sur mon système. J'ai essayé d'en comprendre les fondements techniques.

Les effets que vous observez sont les comportements directs et prévisibles d'un système audio numérique synchrone ("Direct Clock") utilisant un convertisseur Non-Oversampling (NOS). Les performances de votre système sont régies par deux facteurs principaux qui varient avec la fréquence d'échantillonnage :

• Les artefacts d'imagerie ultrasoniques : une conséquence du processus de conversion NOS, dominante aux basses fréquences d'échantillonnage.
  
• La stabilité du synthétiseur d'horloge : une caractéristique de la PLL interne du streamer Diretta, dominante aux hautes fréquences d'échantillonnage.
  

Votre "sweet spot" à 8fs est le point où les impacts négatifs de ces deux facteurs sont simultanément minimisés.

Analyse par fréquence d'échantillonnage

1. Basses fréquences d'échantillonnage (ex: 44.1kHz) : Dureté due aux artefacts d'imagerie
   Lorsque votre DAC Holo May effectue une conversion Non-Oversampling à une fréquence native comme 44.1kHz, son réseau de résistances R2R produit le signal audio désiré (0-22.05kHz) ainsi que de puissantes "images" ultrasoniques de ce signal. La première et la plus puissante de ces images est centrée à 44.1kHz.
   
   • Le mécanisme de la dureté : L'étage de sortie analogique du DAC ne fournit qu'un filtrage doux. Une quantité significative de cette énergie ultrasonique est donc transmise à votre amplificateur. De nombreux amplificateurs, lorsqu'ils reçoivent des signaux puissants hors de la bande audio, génèrent de la distorsion d'intermodulation (IMD). Ce processus crée de nouvelles fréquences non musicales à l'intérieur de la bande audible, qui sont perçues comme de la dureté, un grain ou un son "numérique" agressif.
     
   • Le rôle de l'horloge précise : Une horloge de haute précision à faible gigue (jitter) garantit que la forme d'onde en escalier du NOS est créée avec une précision maximale. Cela a pour effet de concentrer proprement l'énergie dans le signal audio fondamental et ses images ultrasoniques, rendant ces dernières plus puissantes. Votre hypothèse est donc correcte dans ses effets : l'horloge précise rend les conséquences des images ultrasoniques — c'est-à-dire l'IMD audible produite par l'amplificateur — plus apparentes.
     
   
   
2. Le "Sweet Spot" (PCM 8fs) : Une convergence de conditions optimales
   Le suréchantillonnage à 8fs dans le streamer Diretta avant d'envoyer le signal au DAC résout les deux problèmes potentiels du système.
   • Élimination des artefacts d'imagerie : En suréchantillonnant à 352.8kHz, la première image ultrasonique majeure est repoussée de 44.1kHz jusqu'à 352.8kHz. À cette haute fréquence, le filtrage analogique natif du DAC est beaucoup plus efficace. Le signal envoyé à votre amplificateur est désormais exempt du contenu ultrasonique à haute énergie qui cause l'IMD, ce qui élimine la source de la "dureté".
     
   • Performance de pointe du synthétiseur d'horloge : La PLL interne du streamer Diretta a un point de fonctionnement optimal où sa stabilité est la plus élevée et sa gigue auto-générée est la plus faible. Votre expérience confirme que la génération de l'horloge pour la fréquence d'échantillonnage 8fs correspond à ce point optimal. Comme votre DAC est asservi à cette horloge, il reçoit un signal avec une précision temporelle maximale.
     
   À 8fs, votre système atteint à la fois un spectre de fréquences propre et sa plus haute fidélité temporelle possible.
   
   
3. Hautes fréquences d'échantillonnage (DSD256+) : Dégradation due à l'instabilité de l'horloge
   Lorsque vous sélectionnez une fréquence d'échantillonnage au-delà du "sweet spot", vous poussez le synthétiseur d'horloge du streamer hors de sa plage de fonctionnement optimale.
   • Le mécanisme de la dégradation : Pour générer les très hautes fréquences d'horloge requises pour le DSD256 ou plus, la PLL du streamer doit utiliser un facteur de multiplication moins stable. À ce stade, la PLL elle-même devient la source dominante de gigue dans votre système.
     
   • La conséquence directe : Étant donné que le re-synchronisation interne du Holo May est désactivée, il n'a aucune capacité à corriger cette erreur de synchronisation. Il utilise donc docilement l'horloge à plus haute gigue fournie par le streamer. Cela introduit des erreurs de synchronisation directes dans le processus de conversion analogique, dégradant la précision de la forme d'onde finale. Vous percevez cela comme une perte de focalisation et un son "tamisé", car la précision ultime de la référence 10MHz est compromise par l'instabilité du synthétiseur.
     

.

[Édition:] Mise en forme pour faciliter la lecture

[KIKIWILLYBEE]

Bonsoir Jean-Luc.
Koukou PiERRE., toujours heureux de te lire , curieux de tes expériences et te trouvant trop rare et si perspicace  … ;-)

Svp ,  Jean-Luc , je me permets, de revenir sur
f. =  Adev. 
Ou Allan déviation , fonction complexe , en référence à un temps , permet d’observer la stabilité temporelle d’un oscillateur , soit sa précision. ou aussi stabilité . Cette lecture se fait sur un temps de référence , correspondant au temps de la mesure et l’expression de la stabilité sur ce temps de référence . Plus simplement la dérive moyenne sur ce temps de référence ou d’observation . De façon standard la lecture de cette précision se fait sur 1 seconde  , F = 1/T. et cela correspond donc sur 1Hz au bruit de phase de l’oscillateur @ 1.Hz. en dBc. … , sur dix hertz , sur un dixième de seconde … etc. , ( le bruit de phase de l’oscillateur à cette fréquence au travers de la fonction complexe ADEV. permet l’expression de la stabilité sur cette fréquence et donc le temps ….)
@ a 1Hz nous avons ainsi la lecture directe de la stabilité , sur une seconde : S-1. ; par exemple sur un oscillateur Hdg celle ci sera de l’ordre de 1E-13., 1o -13. , ou encore 1o-4 ppb. S-1.  et ainsi exprimer de façon standard ADEV.S-1.  =  Dixième de milliardième de seconde  / sur une seconde  -> pour ADEV.S-1 =  1.E-13, 1o-13 , o. Ooo 1 ppp.S-1

À propos de Diretta , il est question très spécifiquement d’un flux , et ici d’un flux ethernet , séquencé en paquets . sous un protocole (tcp-ip, udp..)
Soit le contexte de l’évaluation d’un flux , et d’un flux 8o2.3  rsx. , les éléments d’évaluations mise en évidence seront LATENCE. (Retard du paquet en temps X 2 ) , DELAY. ( delta de temps inter paquet :  en temps ) , OVER ALL PAQUET LATENCY  et PAQUET LOSS  en %…
Tandis que l’évaluation globale de la précision du système , celui ci modélisé comme SDA.  SERIAL DATA APPLICATION. (Soit émetteur, récepteur , adossé à un oscillateur) se fera statistiquement au travers du BER.  Bit Error Ratio. ( ex: qui peut être compris entre 1o-9 jusqu’à 1o-13 pour les applications critiques soit 1 bit perdu pour tout les dix milliards …),
(Si il y a mesure de la trame , ou de la distribution des paquets , de sa dérive ; Ici il est mesuré la constance de la distribution des paquets, au travers cela d’un équipement conséquent (Telecom. HF. ex keysight. Agilent. ,Téktro. …. , précis à 1o-13 S-1. Mini , (analyseur de trame )). la régularité , constance , ou même le front du paquet pourrons être soumis à une évaluation temporelle …)
…

Bien a vous,
Cordialement,
W ::-)

https://en.wikipedia.org/wiki/Allan_variance

[Bear]

Bonsoir Willy,

Merci pour ces précisions. Likewise, je t'ai trouvé discret sur le fil du Gustard R30 J'aurais attendu de lire des compte-rendus gourmands de tes écoutes... que néni. J'ai regretté. Du coup, je me suis dit que la seule façøn de savoir si le R30 était 'meilleur' au sens où il intégrait mieux le signal d'horloge que mon Holo qui n'a pas de PLL synchronisée à une horloge à 10MHz en interne, je me suis dit donc que la seule façon de juger était d'en commander un. Je n'ai pas essayé une fois, mais deux et trois, et Audiophonics n'a pas voulu de ma commande, malgré mes supplications par email. J'étais très déçu et me suis dit que l'Univers ne voulait pas que je dépense de sous à cet endroit. Fidèle je resterai au DAC Holo

Pour revenir à Diretta, et au delà de savoir comment il fait pour parvenir à ce résultat, ce qui m'a un peu occupé ces jours derniers quand même, je dois dire que c'est tout à fait exceptionnel. Sur mon système, la connexion directe entre le serveur DPDK et le DST-0 est sublime ; comme dirait notre ami Franck, cela va beaucoup plus loin

[KIKIWILLYBEE]

Heu..
J’ai honte du coup..!,
Acceptes , stp., mes excuses….pour cela …
(C’est aussi un exercice que je ne maîtrise pas….
Je n’ai pas la facile faconde et l’aisance nécessaire..
Et cela doit , peut-être m’engager trop.’?)
Quoi qu’il en soit cela est d’abord une dichotomie delta/sigma. Vs. R2R. ,
Comme tu sembles l’avoir expérimenté avec le X3o..?

Et j’ai bien conscience de l’intérêt (supérieur) de Diretta…..,
Mais l’ergonomie m’en laissera éloigné,
(Je ne peux pas être le seul utilisateur …..)
…

Bonne soirée à tous,
Très cordialement,
W :-).

[Bear]

Quoi qu’il en soit cela est d’abord  une dichotomie delta/sigma. Vs. R2R. ,
Comme tu sembles l’avoir expérimenté avec le  X3o..?

Oui c'était bien là mon point: voir comment l'apport d'une horloge au point critique de restitution pourrait améliorer la restitution musicale d'un DAC R2R. Les références prestigieuses comme MSB et Rockna semblent montrer que c'est un chemin idéal. J'aurais voulu tester par moi-même, mais je n'ai pas dit mon dernier mot, car Audiophonics a des concurrents...

Et j’ai bien conscience de l’intérêt  (supérieur) de Diretta…..,
Mais l’ergonomie m’en laissera éloigné,
(Je ne peux pas être le seul  utilisateur …..)

Je me rappelle que tu avais partagé cette objection avec moi. De mon point de vue, Diretta, c'est avant tout une certaine idée de la reproduction musicale, de l'immersion dans la musique, qui peut se goûter à plusieurs niveaux:

• tu peux avoir un player comme HQPlayer ou Audirvana (ce n'est pas limitatif) dont le driver ASIO ou ALSA soit Diretta et juste offrir cette connexion aux autres utilisateurs de ton système qui sont moins impliqués que toi dans la communion musicale
  
• tu peux avoir un niveau plus immersif, à partir du même hardware, en ajoutant dans la boucle un serveur DPDK, et utiliser alors MemoryPlay qui est moins 'user-friendly' lorsque tu recherches une expérience plus immersive.
  

Je crois donc que la solution Diretta peut se décliner à plusieurs niveaux de compléxité et d'immersion. Mais le point d'entrée est un peu ardu. Je me rappelle avoir été rebuté au début (surtout par Windows) et avoir eu besoin du support de la communauté pour persévérer...

[Le dom]

Même sans utiliser DPDK, MemoryPlay offre déjà une qualité sonore de haut vol.
Depuis que j'ai développé ma petite application, c'est beaucoup plus pratique de naviguer dans ma bibliothèque et de lancer l'écoute d'un album. Le seul écueil por moi pas de Qobuz au même niveau de qualité sonore car je n'ai pas droit à l'API Qobuz pour pouvoir l'intégrer à mon application.