Protocole Diretta

[Steph44200]

En français :

L'hôte est synchronisé avec la cible afin de gérer le traitement moyen de cette dernière. Les paquets sont transmis aussi souvent que possible à intervalles courts et constants afin de gérer le traitement moyen. La transmission est contrôlée par la prévision des tampons de la cible.
Ainsi, les fluctuations de consommation d'énergie d'un lecteur, comme la cible, sont lissées autant que possible.

Cette méthode n'est pas fondamentalement supérieure aux autres systèmes de transmission. Nous proposons cependant une approche différente.
Similaire à la synchronisation USB , la cible ne change pas de vitesse car l'hôte se synchronise. Il n'y a pas de contrôle de tampon/flux comme avec la synchronisation USB. Une connexion entièrement isolée peut être utilisée, ainsi que des fibres et autres câbles, car il s'agit d'Ethernet. Aucun traitement complexe, comme les requêtes de plage de fichiers UPnP, n'est requis. Aucun traitement complexe, comme la synchronisation de plusieurs périphériques AES67, n'est non plus requis.

[floyer]

Au sujet de la grille de calcul, jusqu’à l’étape 3, que du calcul mécanique… les étapes 4 et 5 sont plus intéressantes. La 5 en particulier.

Étape 5 / La tolérance au jitter correspond au retard (latence) que prend le target avant d’envoyer le son au DAC. Si tu choisis trop grand, chaque changement de morceau prendra autant de temps (le système sera peu réactif a priori). Si tu choisis trop petit, (disons t), si l’hôte a le malheur de « dormir » un temps t avant d’envoyer son paquet, tu auras un craquement. Avec t bien choisi et un hôte dédié à la musique peu de chance, mais l’architecture Windows fait que le système peut être monopolisé par un driver et empêcher l’exécution de driver concurrent. (Cf mesure Latencymon). Il est proposé 3x une période liée à l’audio… j’aurais proposé plutôt 1,5x ou 2x une mesure latencymon (à titre indicatif). Nb : dans les exemples on est à environ 1ms… c’est très réactif, mais certains drivers peuvent mettre à mal ce paramètre. Cf https://resplendence.com/images/latencymon_drivers.jpg et les 4,5ms !!!

Étape 4/ Pour le minimum, je ne sais pas… il est proposé 0,75x le cycle moyen, mais je ne sais pas comment ce chiffre est pris en compte. Il est assez logique que si un paquet met trop de temps pour arriver (système qui « dort »), les suivants doivent être rapprochés pour rattraper le retard… rapprochés de combien ? 1% (donc facteur 0,99) serait très bien compte tenu de l’objectif de Diretta de lisser le flux… mais trop risqué (à chaque fois que l’hôte prend trop de temps on n’arrive pas à rattraper le retard). Là, avec 0,75 en mini et 3 en maxi, en cas de retard de 2 unités (le maximum), en 8 paquets, le retard est résorbé. Ainsi — avec un système bien réactif, pas de driver mal optimisé — pour rendre le débit plus constant, il semble opportun de pousser le mini… de 0,75 à 0,8… 0,85… sachant que l’on donne moins de marge de manoeuvre pour résorber un retard. Évidement, ne pas dépasser 1x ni même atteindre.

Bon, cela reste de la théorie, reste à voir la pratique… je laisse ceux qui ont une installation Diretta fournir un retour. (Surtout que je n’ai pas l’algorithme de synchronisation de Diretta). Et un paramètre pour un système bien optimisé peut être désastreux pour un autre. (Je ne sais pas non plus s’il est préférable de compenser un retard rapidement ou non d’un point de vue impact de la charge de traitement donc la consommation électrique et donc la qualité audio)