Diretta audio protocol

[Bear]

Est-ce que les paramètres passés à Diretta sont les mêmes dans les deux distributions ?

Avez-vous observé une différence majeure entre noyaux chargés en RAM ou exécuté normalement ? Si oui, dans quels domaines ?

[Le dom]

Oui Pierre, le paramètres Diretta sont les mêmes dans les deux distributions et j'utilise les mêmes applications audio (Upmpdcli + MPD). On ne peut pas faire plus simple.

---

(02-21-2022, 11:32 AM)Patatorz a écrit : Ne serait ce pas également un écart lié aux noyaux entre gentooplayer et audiolinux.

Sans doute, mais le deux distributions donnent toutefois d'excellents résultats.

[Le dom]

(02-20-2022, 04:16 PM)Patatorz a écrit : Je tourne avec celui-ci en RAM (Mode 5): 5.16.7-xanmod1-x86_64-GP-XA-MIN-GP2-SKYLAKE

Et chez toi, que recommenderais-tu ?

Finalement, je fonctionne comme toi depuis tout à l’heure. J’avoue que je m’étais axé sur les kernels RT mais ce 5.16.7-xanmod1-x86_64-GP-XA-MIN-GP2-SKYLAKE donne de forts bons résultats en terme de SQ sur GentooPlayer. Je le préfèrerais même à AudioLinux.

[Patatorz]

Ça doit être l’effet des kernels > 5.16 comme mentionné par Bear et Patatras.

Bear avait indiqué que les kernels > 5.16 (si je me souviens bien) faisaient aussi bien que les RT d’où mes essais. 

Vivement que diretta passe les targets en 5.16 ou alors utiliser 2 gentooplayer sur target et host : @Pascal64 tu devrais essayer :-)

[patatras]

Et le 5.17 qui est fameux pour aller plus loin...

[Bear]

J'ai aussi été étonné de percevoir des différences notables à l'écoute entre différentes versions du noyau.

J'ai essayé de comprendre, même si j'ai l'humilité de penser que je n'ai pas les compétences requises pour avoir une vision complète du sujet.

Un élément qui me parait pertinent pour expliquer l'amélioration de la qualité perçue est le sujet de la latence offerte par le noyau et sa capacité à adopter un fonctionnement 'temps réel' qui est de notoriété publique un élément important dans la reproduction musicale.

Le mainteneur de la distro "CCRMA" de Fedora, que j'ai déjà cité, nous confirme que la version 5.16 du noyau de Fedora embarque maintenant les fonctionnalités de préemption dynamique: https://cm-mail.stanford.edu/pipermail/p...18899.html

Mais j'ai aussi noté, en testant hier la dernière mouture du noyau 5.17rc5 sur mon système, une forme de régression, en particulier lorsque ce noyau est installé sur mon NAA. J'ai essayé de creuser et de mesurer ce qui se passait en terme de latence.

Les spécialistes des applications Linux temps réel (dont je viens de découvrir que le CERN voisin de chez moi était un acteur majeur), mettent à disposition un outil de mesure facile de mise en oeuvre (il suffit de le compiler après l'avoir récupéré sur GitHub). Voir ici: https://wiki.linuxfoundation.org/realtim...test/start

Les résultats sont intéressants, même s'il ne s'agit pour moi que d'une corrélation et que je n'ai pas les moyens de dire qu'il s'agit d'un rapport de causation...

Sur le NAA avec le noyau 5.17rc5 en mode préemption dynamique, mais sans activer le 'full-preemt':



Si j'active le mode 'full-preempt' sur ce noyau, la latence maxi sur ce noyau (colonne de droite) diminue:



Si je redescends sur la version 5.16.10 du noyau sans 'full-preempt':



Enfin, si j'active le full-preempt sur ce noyau:



Voila pour les observations que je peux faire sur mon système.
Les mesures mettent en évidence que la latence du noyau 5.16.10 est bien plus faible que celle de la version RC (qui n'est pas définitive) du 5.17. C'est important sur mon NAA, alors que sur la machine qui exécute HQPe chez moi, c'est plutôt la 5.17 qui donne les meilleurs résultats, car elle semble mieux répartir la charge entre processeurs et mieux prendre en compte les caractéristiques de ma machine qui est récente...

Je précise que mon NAA est une petite machine, et qu'elle n'est pas dotée d'un processeur de compétition
Je ne doute pas que certains d'entre vous obtiennent de bien meilleures mesures et mon objectif n'est pas de lancer ici la compétition de celui qui a la meilleure latence sur son système, mais juste de partager mes observations et la corrélation que j'ai observée entre latence et qualité audio reproduite.

Je précise que les mesures ont été faites chacune peu après le redémarrage du système et qu'une pollution de ce redémarrage sur les mesures est possible. Enfin, ces mesures sont faites en charge, comme le recommande la procédure, ie avec les drivers ALSA de Diretta chargés, le NAA de HQPlayer en fonction et que les quatre mesures ont été faites sur le même album de musique...

Dans tous les cas, je me régale de l'écoute de ce sytème avec les drivers ALSA de Diretta. La mise à disposition de ces drivers est, de mon point de vue, une avancée majeure en matière de qualité.

[floyer]

Sur Diretta.link :

Citation : The Host operates in synchronization with the Target to average processing by the Target. Packets are transmitted as often as possible at constant short intervals in order to average processing.The transmission is controlled by forecasting Target buffers.
In this way, fluctuations in power consumption of a player as the Target is averaged as much as possible.

Je pensais naïvement que la jigue pouvait être corrigée par des buffers à la réception (Quand les buffers ne suffisent pas, cela s’entend franchement… craquements). … mais je comprends que cela entraîne des fluctuations dans la consommation d’énergie. La page de Diretta indique que l’intérêt du protocole réside dans le flux constant, ce qui nécessite une latence faible… d’où des patchs ad’hoc.

[Bear]

(02-22-2022, 12:29 PM)floyer a écrit : La page de Diretta indique que l’intérêt du protocole réside dans le flux constant, ce qui nécessite une latence faible… d’où des patchs ad’hoc.

Merci de ton intervention. J'ai expliqué plus haut que les patchs RT n'étaient plus d'actualité, car ils sont maintenant intégrés dans le noyau à partir de la version 5.16 de celui-ci.

[floyer]

Merci pour la précision. Du coup, la page https://wiki.linuxfoundation.org/realtime/start est curieuse : il est question d’un patch 5.16-rt. Il existe donc bien encore des patchs RT. Mais je comprends que la version 5.16 intègre (d’autres) améliorations de ce côté. (https://www.phoronix.com/scan.php?page=n...Sched-Core)

[Bear]

(02-22-2022, 12:53 PM)floyer a écrit : Merci pour la précision. Du coup, la page https://wiki.linuxfoundation.org/realtime/start est curieuse : il est question d’un patch 5.16-rt. Il existe donc bien encore des patchs RT. Mais je comprends que la version 5.16 intègre (d’autres) améliorations de ce côté. (https://www.phoronix.com/scan.php?page=n...Sched-Core)

Il n'est pas exclu que toutes les distros de Linux n'aient pas activé les fonctions préemptives du noyau par défaut.
C'est le cas pour Fedora. Voir ici: https://koji.fedoraproject.org/koji/buil...ID=1918958 le changelog du noyau 5.16.10 de Fedora. En faisant une recherche sur PREEMPT, on voit que ces fonctionnalités sont embarquées à partir de la rc0 du noyau 5.16.

C'est d'ailleurs ce que souligne la personne qui maintenait la version RT du noyau de Fedora (CCRMA) que j'ai citée dans ma contribution: https://cm-mail.stanford.edu/pipermail/p...18899.html

Du coup, il suffit de passer 'preempt=full' comme commande au démarrage du noyau, ce qui se fait sous Fedora par la commande:

sudo grubby --update-kernel=ALL --args="preempt=full processor.max_cstate=1 idle=poll"