DirettaRendererUPnP

[Bluevelvet]

Bonsoir Dominique, 


je suis allé vite en besogne, entre temps j'avais installé TUNE sur Fédora et à la lecture de ton message j'ai tout désintallé, à savoir :

Ce qui a été retiré aujourd'hui :

  TUNE Server (rm -rf /opt/tune-server)
  ffmpeg 7.1.2 (dnf remove)
  Python pip/devel (dnf remove)
  portaudio (dnf remove)
  Fichiers config TUNE (~/.tune/, tune_server.db)
  Service systemd (tune-server.service)
  Utilisateur système (tune-server user/group)

  Tune installait les ffmpeg 7.x


Système propre maintenant — ffmpeg 8.0.1 optimisé, tweakés.


J'ai un peu bataillé pour faire le partage samba (jamais fait) de la bibliothèque locale en ssd sur le server Fedora avec le server Tune sur windows. Ca fonctionne, quoique, j'ai constaté une latence au lancement de certains albums et au changement de morceaux avec la bibliothèque locale (SSD Fedora partagée via Samba vers TUNE Windows). Pas de problème avec Qobuz.

Délais de plusieurs secondes dans certains cas.

Question : vaut-il mieux déporter le SSD USB directement sur le server TUNE Windows
pour éliminer le partage réseau ?

Perso je l'ai installé sur mon PC audio serveur sous Windows 11 tout comme Audirvana ou LMS et même minimserver maintenant.

  
je vais aller dans ce sens, j'ai Minimserver sur Fédora ainsi que LMS (que je n'utilise plus depuis que j'utilise JPLAY).

Question le Roon Server, il faut également le désinstaller de Fedora, et n'utiliser que celui qui se trouve sur windows ?

Idem pour le ssd usb bibliothèque locale, faut-il mieux le déporter sur le PC windows ?


Par ailleurs, franchement, pour ceux qui n'ont pas de licence Roon, TUNE est une très bonne alternative.


Pas de différence sonore, voire légèrement meilleurs pour DRUPnP+TUNE vs DRUPnP+slim2UPnP+Roon


Pour finir des mesures de l'activité du server Fedora avec DirettaRenderer v 2.4.3

: 

Code :

RAPPORT - DirettaRendererUPnP V 2.4.3 Performances système Fedora RT Matériel testé Processeur : Intel Core i3-6100U @ 2,30 GHz Architecture : 2 cœurs physiques Configuration : SMT désactivé Noyau : CachyOS temps-réel (RT) 1. Charge CPU et répartition par cœurs Mesures principales (lecture 96 kHz/24 bits en cours) Charge moyenne : 0,02 / 0,04 / 0,07 (load average) CPU global (top/mpstat) : ~2% user ~2,5–3,5% système ~2% IRQ/softIRQ >90% idle (92–94%) Processus audio principaux DirettaRendererUPnP : 2–3% CPU RoonAppliance : 3–4% CPU Conclusion Plateforme très largement sous-utilisée, même en lecture haute résolution. Le CPU n'est pas un facteur limitant. 2. Détail par cœur (mpstat -P ALL) CPU 0 (système/UPnP/autres tâches) Idle : 96–98% Pointes : 1–3% usr/sys/irq Rôle : cœur de fond, très calme CPU 1 (audio + décodage) Idle : 87–90% Activité : ~3% usr, ~5–6% sys, ~3% irq, ~2% soft Utilisation totale : ~10–13% maximum Marge disponible : 87% Conclusion Configuration confirmée : CPU 0 en fond de tâche, CPU 1 dédié audio avec marge énorme pour le traitement temps réel. 3. Threads Diretta : affinité et scheduling Commande d'inspection bash ps -eLo pid,psr,cls,rtprio,pcpu,cmd | grep -i diretta Résultats Threads UPnP/main : Classe TS (time-sharing) PSR = 0 (cœur 0) Charge très faible Thread audio/décodage : PSR = 1 (cœur 1) Classe FF (SCHED_FIFO) rtprio = 50 %CPU ~1% (cohérent avec 10–13% agrégé sur cœur) Conclusion Thread audio/décodage bien isolé sur cœur 1 en temps réel strict (SCHED_FIFO, priorité 50). Répartition logique "worker/SDK/UPnP" vs "audio/decode" réellement appliquée. 4. IRQ réseau/USB et affinité Inspection /proc/interrupts IRQ 123 : xhci_hcd (contrôleur USB → DAC) IRQ 127 : enp0s31f6 (interface réseau Diretta) Affinité vérifiée text /proc/irq/123/smp_affinity_list → 0 /proc/irq/127/smp_affinity_list → 0 Conclusion IRQ USB audio et réseau bindées sur cœur 0 (cœur système). Le cœur 1 (audio) est ainsi libéré des interruptions matérielles, ce qui maximise la stabilité du thread temps-réel SCHED_FIFO priorité 50. 5. Latence de scheduling (cyclictest, gouverneur ondemand) Test effectué bash sudo cyclictest --mlockall --threads=1 --priority=95 \   --interval=1000 --affinity=1 --duration=60 Résultats text T: 0 (...) P:95 I:1000 C:21679 Min:1 Act:11 Avg:10 Max:28 Cycles : 21 679 réveils sur 60 s (intervalle 1 ms) Latence minimale : 1 µs Latence moyenne : 10 µs Latence maximale : 28 µs Interprétation Pour un système généraliste RT, Max < 50 µs = très bon. 28 µs = excellent jitter de réveil sur cœur audio. 6. Latence améliorée (gouverneur performance) Modification gouverneur CPU bash sudo cpupower frequency-set -g performance Test cyclictest pendant lecture 96/24 bash sudo cyclictest --mlockall --threads=1 --priority=95 \   --interval=1000 --affinity=1 --duration=60 Résultats après passage en mode performance text T: 0 (...) P:95 I:1000 C:59993 Min:1 Act:12 Avg:10 Max:25 Latence minimale : 1 µs Latence moyenne : 10 µs Latence maximale : 25 µs Conclusion Amélioration mesurable : passage de 28 µs (gouverneur ondemand) à 25 µs (gouverneur performance) pendant lecture réelle 96/24. SYNTHÈSE FINALE ✅ Isolation cœur audio/decode parfaite ✅ Gigue ultra-faible (25 µs max avec gouverneur performance) ✅ Marge CPU énorme (87–90% libre sur cœur audio) ✅ IRQ USB et réseau correctement routées sur cœur 0 (libère cœur 1 audio) ✅ Thread temps-réel SCHED_FIFO priorité 50 actif et vérifié ✅ Noyau CachyOS RT opérationnel ✅ Configuration DirettaRenderer 2.4.3 opérationnelle et optimisée Plateforme Fedora RT avec noyau CachyOS parfaitement configurée pour audio haute résolution.