Diretta audio protocol

[zaurux]

(02-22-2022, 12:11 PM)Bear a écrit : ...

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é.

Très intéressant... malheureusement, je n'ai pas beaucoup de temps à consacrer à cette quête.. vivement un peu de temps.
En attendant, même avec un kernel un peu plus ancien et optimisé pour un UP Xtreme  
https://github.com/raess1/UPxtreme-RT-kernel




Stabilité, équilibre des charges entre cœurs et latence réduite ==> SQ   

[floyer]

Je n’ai pas compris cette histoire de charge équilibrée entre les cœurs. Si les processus n’ont besoin que de deux cœurs pour fonctionner, cela peut être toujours les 1 et 2, laissant les autres tranquilles sans que cela ne pose problème. Pire, avec les processeurs hybrides, certains cœurs sont moins performants que d’autres… on a intérêt à ne les utiliser que si nécessaire.

Ce qui importe est d’avoir une latence faible (donc pas de processus basse priorité qui bloque un de plus haute priorité à cause d’un verrou par exemple). Je suis assez bluffé par les résultats !

[Bear]

(02-22-2022, 02:30 PM)zaurux a écrit :

(02-22-2022, 12:11 PM)Bear a écrit : ...

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é.

Très intéressant... malheureusement, je n'ai pas beaucoup de temps à consacrer à cette quête.. vivement un peu de temps.
En attendant, même avec un kernel un peu plus ancien et optimisé pour un UP Xtreme  
https://github.com/raess1/UPxtreme-RT-kernel




Stabilité, équilibre des charges entre cœurs et latence réduite ==> SQ   

Salut Stéphane,

Peux-tu montrer les paramètres utilisés pour ta mesure ?

C'est important, comme indiqué dans la procédure de mesure, de laisser tourner le test suffisamment longtemps pour capter les mesures maximales de latence... Or il semble que le temps auquel tu as fait la capture que tu partages est très court...

Elle pourrait accréditer ce qu'écrit le gars de CCRMA, qui conclue que le noyau 5.16 est moins performant que le noyau 5.14.8 qu'il avait optimisé avec les patchs RT qui vont bien.
Encore une fois, on n'est pas lancé dans une compétition et je me réjouis pour toi que tu aies une version de noyau optimisé pour ton NAA. D'où ma question: as-tu fini par acheter une UP ?

Enfin pour Diretta, ce qui pilote la connexion USB c'est le target, une carte Lucia dans ma configuration, dont le noyau a été très optimisé par Diretta. Et là, il n'est pas possible de mesurer quoi que ce soit...

---

(02-22-2022, 02:35 PM)floyer a écrit : Je n’ai pas compris cette histoire de charge équilibrée entre les cœurs. Si les processus n’ont besoin que de deux cœurs pour fonctionner, cela peut être toujours les 1 et 2, laissant les autres tranquilles sans que cela ne pose problème. Pire, avec les processeurs hybrides, certains cœurs sont moins performants que d’autres… on a intérêt à ne les utiliser que si nécessaire.

Ce qui importe est d’avoir une latence faible (donc pas de processus basse priorité qui bloque un de plus haute priorité à cause d’un verrou par exemple).

Nous sommes d'accord. Sur le serveur HQPe, on a peu de moyen d'agir sur ces sujets, car le développeur, Jussi Laako, a écrit des algos sophistiqués de répartition de charge entre les processeurs. Mais comme il s'agit d'un serveur, qui est connecté au NAA par Ethernet, cela ne compte pas, ou peu.

Sur le sujet qui nous occupe dans ce fil, Diretta a fait un très bon job en permettant de donner des priorités 'temps réel' au process critique, au travers d'un fichier de configuration.

Cela n'empêche qu'il me parait important d'accompagner ce développement par le choix d'un noyau adapté.
Enfin c'est ma compréhension des choses...

[rastabill]

(02-22-2022, 12:11 PM)Bear a écrit : 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é.

Superbe résultat sur la latence sur ta petite machine   difficile de descendre plus bas. 
Quel type de carte mère et proc tu utilise?

[zaurux]

(02-22-2022, 02:40 PM)Bear a écrit :

(02-22-2022, 02:30 PM)zaurux a écrit : ...
Très intéressant... malheureusement, je n'ai pas beaucoup de temps à consacrer à cette quête.. vivement un peu de temps.
En attendant, même avec un kernel un peu plus ancien et optimisé pour un UP Xtreme  
https://github.com/raess1/UPxtreme-RT-kernel

Stabilité, équilibre des charges entre cœurs et latence réduite ==> SQ   

Salut Stéphane,

Peux-tu montrer les paramètres utilisés pour ta mesure ?

...

Pardon, je n'ai pas précisé. Ce n'est pas ma mesure mais celle liée au lien qui est affiché juste au-dessus.
J'ai hésité à passer à une carte UP mais avec piCorePlayer + NAA 4.2, je suis resté sur mon Allo.
Et je n'ai tenté la démarche (un peu complexe) de récupérer le nécessaire pour compiler l'utilitaire de latence afin de testé mon NAA.
Sur les Pi, vitOS en a fait un argument et Atonello (GentooPlayer) avait communiqué certains éléments mais il restait assez dubitatif sur cette démarche (au delà d'un certain niveau).

Comme toi, je ne maîtrise pas tous les éléments de la délicate architecture "hardware/OS".
La latence est corrélée à la qualité finale mais on reste tributaire des choix hardware et de l'optimisation de ce qui fait le lien (drivers/modules et kernel). 
Un rapide post de vulgarisation (parmi d'autres) :
https://www.diyaudio.com/community/threa...st-6928472

[floyer]

La démarche est décrite pas par pas avec des lignes de commandes à saisir sans trop se poser de question… mais pour un Linux Debian ou dérivé (Ubuntu…). Pour un Linux RedHat (Fedora…), il faudra transposer.

Ici https://unix.stackexchange.com/questions...-in-ubuntu on propose la commande :

sudo yum groupinstall 'Development Tools'

Reste libnuma-dev. Un coup de sudo yum install libnuma-devel devrait faire le job.

Ensuite dérouler les commandes après le sudo apt-get.

[Bear]

(02-22-2022, 03:13 PM)rastabill a écrit : Quel type de carte mère et proc tu utilise?

C'est un Intel i5-1135G7 monté dans un petit PC industriel : https://www.onlogic.com/ml100g-53/

J'avais besoin de deux ports RJ-45 pour Diretta

[zaurux]

(02-22-2022, 04:20 PM)floyer a écrit : La démarche est décrite pas par pas avec des lignes de commandes à saisir sans trop se poser de question… mais pour un Linux Debian ou dérivé (Ubuntu…). Pour un Linux RedHat (Fedora…), il faudra transposer.

Ici https://unix.stackexchange.com/questions...-in-ubuntu on propose la commande :

sudo yum groupinstall 'Development Tools'

Reste libnuma-dev. Un coup de sudo yum install libnuma-devel devrait faire le job.

Ensuite dérouler les commandes après le sudo apt-get.

Je regarderai en télétravail..  c'est pour une rpi donc Arm et s'il on teste sur plusieurs kernel, il faut avoir les packages sources parfois "exotiques" et pas toujours à disposition (sauf distribution officielle, ex : 5.10.77 pour PiCore).

[floyer]

Pour compiler des programmes, c’est un dérivé de Debian, donc les commandes sont les mêmes.

Tu risques d’avoir des soucis avec la bibliothèque numa, ainsi, taper sudo apt-get install build-essential sans le libnuma-dev.

Ensuite, on déroule comme documenté mais avec un make NUMA=0 à la place du make all.

(Pas testé…)

[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)

Ici (https://ubuntu.com//blog/industrial-embe...ystems-iii), une explication de la nuance qui existe entre noyaux 'low latency' (qui est le cas des noyaux Fedora 5.16 si l'on active preempt=full), et noyaux RT. Les noyaux 'low latency' sont suffisants pour les applications dont la latence doit être inférieure à la milliseconde. En dessous, le recours aux noyaux RT est nécessaire, mais au prix de difficultés de compatibilité avec les drivers, etc...

Dans les mesures que j'ai faites et refaites, on était presque toujours en dessous de 100us, soit 0.1ms... cela me parait bien

Sous Ubuntu. il existe deux versions du noyau, l'une 'générique' et l'autre 'low latency' : voir ici https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.16/

Ce n'est pas le cas sous Fedora: https://koji.fedoraproject.org/koji/pack...ackageID=8