Aménagement sur mesure, Monitoring PSI Audio & Optimisation Linux (version 6)

[zaurux]

Intellectuellement la démarche est bluffante.. et nécessite un investissement qui est nettement supérieur au temps que je souhaiterai aujourd'hui consacrer à cette activité !
Chapeau. De mon côté, je reste calé sur un système plus classique mais avec un suivi de la latence qui me va très bien.. le reste de mon travail est sur l'acceptabilité de mes imperfections !! 
En évitant de tomber dans la paranoïa.
Donc je me limite à quelques scripts powershell pour évaluer de temps à autre mon serveur audio sous Win11 IoT... et sortir du DSD via Diretta pour alimenter mon dac Holo.

J'avoue que c'est toujours tentant, voire enivrant d'explorer d'autre voie.. j'évite les tentations. 
 Sur la latence, sauf erreur d'échelle ou de calcul (mesure via ETL), c'est de l'ordre de 0,4µs.. ensuite selon les drivers et surtout l'occupation CPU.

Encore une fois.. suis bluffé par la doc mise à disposition et les choix.

[Alain_CH]

Bonjour Zaurux,

Merci beaucoup pour votre retour et pour vos compliments sur le dossier, cela fait vraiment plaisir à lire ! C'est un réel plaisir d'échanger entre passionnés.

Pour rebondir sur votre message, je comprends tout à fait que l'investissement en temps puisse faire peur à la lecture d'une documentation aussi dense.

Cependant, toute l'ingénierie lourde étant déjà faite et les scripts validés, la mise en place sur un système Linux standard est en réalité extrêmement rapide. 
Techniquement, pour adapter les variables à votre nom d'utilisateur et déployer les 5 à 7 fichiers de configuration Systemd, il ne faut probablement pas plus de 10 à 30 minutes montre en main (demeure réservé un CPU Intel que je n'ai pas testé - l’architecture est différente mais l'isolation par slice demeure inchangé.) Si un jour la curiosité l'emporte sur la sagesse, vous verrez que la montagne est beaucoup moins haute qu'elle n'en a l'air !

Concernant votre relevé de 0,4 µs, les informations que je trouve font que c'est un chiffre qui interpelle et qui, je pense, s'explique très probablement par un biais de mesure ou d'échelle de l'outil de traçage (ETL) :

• Sur une architecture x86/x64 classique, le simple temps de commutation de contexte (Context Switch) et le routage d'une interruption matérielle (ISR/DPC) par le noyau prennent déjà entre 1 et 2 microsecondes au minimum. D'ailleurs, dans la documentation officielle du Windows Driver Kit, Microsoft recommande que les routines DPC s'exécutent en moins de 100 µs et les ISR en moins de 25 µs. Ainsi, descendre en dessous de la microseconde globale est structurellement impossible sur un OS standard doté d'un noyau monolithique comme Windows ou Linux (d'où l'intérêt de contourner cette limite via les slices).
  
  
• Le piège du "Self-Time" : Dans l'analyseur Windows Performance Analyzer (WPA), 0,4 µs correspond souvent au temps d'exécution propre d'une fonction isolée d'un pilote (une fois qu'elle a déjà le contrôle du CPU), et non pas à la latence globale de la chaîne, du signal électrique jusqu'au traitement audio.
  
  
• La confusion ms / µs : Il arrive fréquemment qu'une valeur de 0,4 milliseconde (ms) soit affichée ou interprétée à cette échelle, ce qui représenterait 400 µs.
  
  

Dans tous les cas, votre configuration (Win11 IoT + Diretta + Holo R2R) est une superbe approche. Le protocole Diretta fait un excellent travail pour décharger le serveur en amont, ce qui explique pourquoi votre système vous apporte autant de satisfaction. L'essentiel reste de profiter de la musique !

Au plaisir de continuer à lire vos retours d'expériences.

[Lapinou]

En résumé, le routage par slices n'est pas un concurrent de la solution globale de Le Dom. C'est un mécanisme chirurgical de distribution des forces du processeur. On pourrait d'ailleurs tout à fait appliquer ce routage par slices au sein de l'OS minimal décrit par le Dom pour cumuler les avantages des deux mondes.

Nous y voilà !!!

Le fait est qu'en ce moment, j'oscille entre "un petit peu" et "beaucoup" de mal avec l'informatique, bien que ce soit mon métier...

Je vais tenter une introspection, on verra bien où ça me mènera !

[zaurux]

Non, il n'y a pas d'erreur mais un traitement différent, ce n'est pas une latence de réaction mais un temps de traitement CPU. En complément, un peu involontairement, j'ai choisi un cpu hyperpuissant pour upgrader mon PC (I9-11900K) pour faire du DSD 1024 confortablement. Sauf que c'est un four !!
Et que j'ai du utilier Trottlestop pour le maintenir à 3ghz (fanless limite).
L'avantage, c'est que la gestion de l'énergie est maitrisée et l'OS n'a pas à gérer les états (P-States, etc).
La dessus, l'OS n'est pas si standard. Win11 mais en version IoT LSTC avec un nombre de services maitrisés et une gestion des drivers optimisés (pas de services asynchrones, télémétrie, etc).
L'objectif est de rendre la gestion des interruptions, non pas canalisées mais si rapidement que le temps cpu est négligeable.
Ce que je surveille, c'est bien le temps cpu de traitement d'une routine DPC
J'avoue que je n'ai pas creusé le fonctionnement fin de l'outil Xperf mais en gros (à préciser), il mesure le delta entre l'entrée et la sortie du traitement par le pilote (le contexte étant déjà intégré). L'outil permet donc d'évaluer la qualité des choix faits pour optimiser au mieux la gestion des pilotes qui restent toujours le maillon faible entre le hardware et l'OS.

EDIT :
Je vais regarder pour modifier le script et rendre l'analyse plus fiable

[Alain_CH]

Bonjour Zaurux,

Merci pour ces précisions, nous parlions effectivement de deux indicateurs différents.
En précisant qu'il s'agit du delta entre l'entrée et la sortie du pilote (l'Execution Time ou Self-Time sous Xperf), ta valeur de 0,4 µs fait totalement sens. Liquider la routine DPC de Diretta en seulement ~1200 cycles d'horloge (à 3 GHz = 0,4 / 0,000333 ) démontre la légèreté de ce protocole et la pertinence de tes optimisations matérielles.

De mon côté, je faisais effectivement référence à la latence globale de réaction (le Dispatch Latency), qui intègre le switch de contexte et l'ordonnancement de l'OS en amont du pilote.

Ta stratégie de bloquer la fréquence à 3 GHz fixes est excellente pour éradiquer le jitter lié aux transitions énergétiques (P-States). En revanche, le i9-11900K reste un sacré défi thermique en fanless !

Puisque tu utilises déjà ThrottleStop pour brider la fréquence, as-tu déjà essayé l'undervolting (via un Offset de tension négatif ou une Curve Optimizer négative dans le BIOS) ?
Compte tenu de tes optimisations, je suis surpris de ne pas te voir le mentionner.

C’est une des solutions que j’ai dû utiliser sur mon CPU du fait de l’encastrement de ma tour M-ATX dans du mobilier. La gestion des flux d’air et la baisse de consommation d'énergie du CPU (moins de courant = moins de chaleur à dissiper) se sont révélées être des arbitrages nécessaires pour une pleine utilisation multi usage de mon R9 9900X.

Au plaisir de continuer à échanger avec toi,
Alain

---

Salut Lapinou,

Je ne suis pas familier avec les codes des forums, mais si je comprends bien, je suppose que je te dois un grand merci pour cette perche tendue.

À bientôt,
Alain

[Le dom]

Bonjour,

En fait le but de nos deux approches n'est pas le même. De mon côté il s'agit effectivement de l'optimisation d'un OS, en l'occurence Fedora44 dans le but de le faire fonctionner de manière la plus optimale possible avec mes applications DirettaRendererUPnP et slim2Diretta.Ce n'est donc pas pour une utilisation plus générale en audio.
La solution d'Alain_CH put s'applique à n'importe quelle distribution Linux et concerne l'optimisation de l'audio de manière générale et concerne donc beaucoup plus de points.
Effectivement il faudrait que je regarde si le routage par slice pourrait apporter quelque chose, de mon côté.
Merci pour l'idée Alain.

[Alain_CH]

La métaphore du Supermarché Audiophile (Version Universelle)

Imaginez que votre ordinateur est un grand supermarché. Les fichiers de musique sont des clients qui veulent simplement passer à la caisse et sortir pour être écoutés.

Sans aucun cloisonnement (Système standard)
Le supermarché est bondé. Vos fichiers musicaux, les mises à jour de l'ordinateur, les pages internet et les logiciels font tous la même file d'attente aux caisses (les cœurs du CPU). La musique avance par saccades, car le caissier s'interrompt sans cesse pour scanner les articles des autres clients. Ce désordre crée de la cohue, de l'attente et de la friture sur la ligne (le Jitter).

Avec un noyau "Low-Latency" ou "Temps Réel"
Le supermarché décide d'ouvrir une caisse rapide. Le client "musique" passe en priorité dès qu'il se présente. C'est beaucoup plus efficace, mais s'il y a un coup de feu ou qu'un autre client prioritaire arrive, cela crée tout de même des micro-bousculades et de la tension pour le caissier.

Avec le cloisonnement par Slices (La solution absolue)
Ici, on change radicalement de méthode. On décide de privatiser une partie du magasin exclusivement pour la musique. On sépare le supermarché en trois zones étanches :

1. Les Caisses Générales (La zone système) : 
   C'est là que vont tous les clients ordinaires, lourds et bruyants (internet, affichage de l'écran, tâches de fond). C'est la cohue, mais ils restent enfermés dans leur coin.
    
   
2. L'Accueil et la Paperasse (La Ruche / L'application) : 
   Une caisse spécifique est réservée pour s'occuper uniquement des commandes de musique (l'interface du lecteur, la gestion du volume). Elle prépare le terrain à l'abri de la foule.
    
   
3. La Sortie Flash Sans Contrôle (Le Sanctuaire / Le flux audio) : 
   C'est une porte de sortie exclusive et directe, réservée uniquement au flux de musique pure. Les données musicales filent sur un tapis roulant en ligne droite, à vitesse constante, sans jamais s'arrêter et sans aucun contrôle à la caisse ou de police sur la route.
   

Ce que cela change concrètement pour l'auditeur

Grâce à cette organisation :
 

• Immunité totale : 
  Même si le reste de l'ordinateur travaille d'arrache-pied (100 % d'activité sur les caisses générales), il est physiquement impossible qu'un processus système vienne bousculer ou ralentir le tapis roulant de la musique.
  

• Régularité absolue : 
  Le flux musical avance avec une précision d'horloge atomique. Les micro-retards de transmission (la gigue ou jitter) s'effondrent, garantissant la plus grande pureté sonore possible que votre matérielle puisse offrir en sortie.
  

En conclusion : 
Vous indiquez seulement à votre OS : 

"J'ai séparé mon processeur en tranches et je te dis à qui elles sont réservées". 

Aucune modification de votre OS existant, aucune surcouche, il n’y a absolument rien d’autre que le simple routage de votre flux audio. 
Cette mise en œuvre peut se faire sur n’importe quel OS Linux. 

Cette méthode a ses avantages, sa neutralité ou ses limites. C’est en cela que la lecture de mon travail peut vous ouvrir la voie, avec mes échecs et mes réussites, les tests et mes réflexions ainsi que des scripts qui fonctionnent. 

À bientôt,
Alain

PS : 
Vous pouvez utiliser un slice pour y enfermer tout et n'importe quoi : les interruptions IRQ de votre carte, le flux du réseau, un moteur de rendu, le signal USB de votre souris… 

C'est bien là l'une des beautés du libre : le comprendre, en faire ce que l'on veut, et le partager pour que quelqu'un d'autre puisse à son tour l'adapter à ses propres besoins.

[Sylvain74]

Bonjour Alain,
Merci pour cette explication imagée qui facilite la compréhension.
Au plaisir de découvrir ton installation.

[ds21]

Bonjour,

C’est le genre de sujet à la mode en ce moment.

Je ne connais rien à linux, je suis parti de ce que je decouvrais totalement lorsque Minh a posté sur le fil consacré à Gentooplayer : https://forum-hifi.fr/thread-20996-post-...#pid945950

J’ai reproduit son paramétrage en l’adaptant (grace à l’IA Claude) à mon système basé sous Gentooplayer sur un serveur Ryzen7 7730U avec uniquement roon (puisque j’ai maintenant la solution Le Dom/fedora optimisé sur un autre mini PC)

J’ai obtenu un résultat vraiment très intéressant avec l’OS Gentooplayer sur un SSD nvme connecté en USB, et la bd musicale sur un SSD 4To branché en USB grâce à un boîtier Inateck sur alimentation linéaire.






Globalement : isolations de CPUs + CPU affinity + gestion des IRQ/CPUs, on arrive déjà à faire beaucoup sans y connaître grand-chose sous Gentooplayer.

Nota: avec le Ryzen7 7730U et l’hyperthreading désactivé, tous les CPU impairs sont inactifs.

Hier soir, seulement roon...



Je serais bien incapable d’affirmer que c’est ce qu’on peut faire de mieux avec ce système, mais avec l’aide de l’IA, on arrive déjà à un résultat tout à fait intéressant.

Cordialement.

[Lapinou]

Je ne suis pas familier avec les codes des forums, mais si je comprends bien, je suppose que je te dois un grand merci pour cette perche tendue.

Tu es bien urbain Alain, mais je n'en espérais pas tant ! C'est plutôt à moi de te remercier pour ton partage, comme je remercie Dominique pour son travail pour Diretta, même si je ne suis pas utilisateur. Simplement parce que tout ça relève d'un état d'esprit bien trop rare de nos jours. D'ailleurs j'ai un peu honte de l'avoir tendue, cette perche !.. mais l'occasion était trop belle !