DirettaRendererUPnP

[Le dom]

DirettaRendererUPnP v2.4.2 est disponible:

Ajouté
--option de décodage CPU (PR #68 par Daniel/Koala887) : une troisième granularité d’affinité CPU qui fixe le thread audio du moteur de rendu (réception HTTP + décodage FFmpeg) à son propre cœur dédié, séparé du travailleur SDK Diretta () et des threads UPnP/position/main plus légers (). Lorsque c’est réglé, le fil audio est également élevé à priorité en temps réel (en utilisant ), puisque le cœur dédié rend cela sûr. Ça revient à quand il est vide (aucun changement de comportement pour les configurations existantes). Des avertissements de chevauchement cross-core sont émis pour les trois combinaisons (audio/décodage, audio/autre, décoder/autre). Également exposé dans le fichier de configuration comme et dans l’interface web (profils complets et minimums) sous « Affinité CPU ».--cpu-audio--cpu-other--cpu-decodeSCHED_FIFORT_PRIORITY--cpu-other--cpu-decodeCPU_DECODE

Fixé
ProtectKernelTunables=affinité IRQ bloquée vraie (PR #68 par Daniel/Koala887) : la directive de l’unité systemd empêchait d’écrire sur , cassant silencieusement la fonctionnalité / fournie dans la v2.4.0. La directive est désormais commentée afin que le wrapper puisse appliquer l’affinité IRQ demandée. Les autres directives de durcissement du systemd (ProtectKernelModules, ProtectKernelLogs, ProtectControlGroups, etc.) restent en place — seule la protection des réglables du noyau est assouplie, et uniquement parce que le script wrapper doit réellement écrire sur .ProtectKernelTunables=truestart-renderer.sh/proc/irq/N/smp_affinity_listIRQ_INTERFACEIRQ_CPUS/proc/irq/

Script d’installation : arrêter le service avant de remplacer le binaire (PR #69 par Daniel/Koala887) : détecte maintenant si DRUP est en cours d’exécution, l’arrête avant de copier le nouveau binaire dans , puis le redémarre une fois l’installation terminée. Auparavant, réinstaller par-dessus un service en cours d’exécution échouait silencieusement car il ne pouvait pas écraser un fichier maintenu ouvert par systemd, laissant l’ancien binaire en place jusqu’au prochain redémarrage.install.sh diretta-renderer.service/opt/diretta-renderer-upnp/cp

• cp

[Bluevelvet]

@Le Dom,

Pour tester la bêta de Tune sur mon serveur Fedora minimal avec DirettaRendererUPnP, quel est ton avis sur la procédure d’installation adaptée à cet environnement ?

Dans la doc, ils donnent les prérequis pour Debian/Ubuntu :

sudo apt update 
sudo apt install python3 python3-pip python3-venv ffmpeg libasound2-dev libportaudio2 portaudio19-dev avahi-daemon 

Sur Fedora minimal, est‑ce qu’il y a des paquets équivalents à installer via dnf, ou rien de particulier à ajouter dans mon cas ?

Pour l’installation de Tune, tu me conseilles quoi sur Fedora minimal :

Option A — Binaire + install.sh

tar xzf tune-server-*-linux.tar.gz 
cd tune-server 
sudo ./install.sh --systemd  # service au démarrage 
 
# ou, pour tester : 
./tune-server 

(avec téléchargement direct sur le serveur ou transfert par SCP depuis mon PC Windows en SSH) ?

ou bien

Option B — Installation depuis la source


git clone https://github.com/renesenses/tune-server-linux.git 
cd tune-server-linux 
 
sudo ./install.sh --systemd 

Tune est alors installé dans 
/opt/tune-server/
 et tourne comme service systemd.


En résumé : sur mon Fedora minimal + DirettaRendererUPnP, tu recommandes plutôt l’Option A (binaire) ou l’Option B (source) ?

[Le dom]

@Bluevelvet:
Salut, et désolé pour le retard concernant ma réponse.
Après essais je ne te conseille pas trop d'installer Tune sur un fedora optimisé aux petits oignons pour DRUP ou S2D car ça rajoute des paquets et ça met le bazar dans les ffmpeg 8.01 tweakés.
Perso je l'ai installé sur mon PC audio serveur sous Windows 11 tout comme Audirvana ou LMS et même minimserver maintenant.

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

[Le dom]

Bonjour Pascal,
Personnellement, j'ai opté pour le SSD qui contient ma bibliothèque sur le PC Serveur Audio sous Windows avec Tune, Audirvana, Minimserver etc...
Cela supprime une source de bruit de plus sur le combo Host / Target Diretta.
J'ai réinstallé entièrement Fedora 43 et je l'ai entièrement optimisé grace à un script entièrement automatisé que je mets au point avec Claude à l'heure actuelle.
Je vais le mettre à disposition assez rapidement.

[Le dom]

DirettaRendererUPnP 2.4.4 est disponible.

https://github.com/cometdom/DirettaRende...#changelog

[Bluevelvet]

Bonsoir Dominique,
Merci pour ton retour et les précisions: 

Bonjour Pascal,
Personnellement, j'ai opté pour le SSD qui contient ma bibliothèque sur le PC Serveur Audio sous Windows avec Tune, Audirvana, Minimserver etc...
Cela supprime une source de bruit de plus sur le combo Host / Target Diretta.
J'ai réinstallé entièrement Fedora 43 et je l'ai entièrement optimisé grace à un script entièrement automatisé que je mets au point avec Claude à l'heure actuelle.
Je vais le mettre à disposition assez rapidement.

J’ai opté pour la même organisation que celle que tu as mise en œuvre :

• migration et déport du SSD/USB sur l’ordinateur Windows,
  
• idem pour Tune server et MinimServer (j’en ai profité pour prendre la licence, même si pour l’instant je ne vois pas encore ce qu’elle apporte de plus (le site MinimServer est assez pénible à lire et à utiliser…).
  
  

Il me reste un point que je n’ai jamais réussi à résoudre, et qui me bloque pour finaliser la bascule :

• Roon Server sous Windows, support Squeezebox activé
  
• DirettaRenderer + slim2upnp à la manœuvre
  

Résultat : côté Roon, la recherche de périphériques Squeezebox mouline et ne trouve rien.
C’était exactement pareil avec squeeze2diretta ou slim2diretta.
La seule fois où la reconnaissance a eu lieu, c’est quand j’utilisais DRUPnP avec squeeze2upnp.

En revanche, la détection est immédiate quand j’utilise RoonServer sous Fedora.
Du coup, si tu as une piste pour comprendre pourquoi Roon sous Windows ne voit pas le “Squeezebox” (slim2upnp / squeeze2diretta / slim2diretta), je suis preneur.

J’aimerais vraiment finaliser la migration sur Windows et réserver le serveur Fedora au tandem DirettaRenderer + slim2upnp.

J'attends avec bonheur ton script automatisé, il se distingue de ton tuto Fedora ?

[Le dom]

Bonjour Pascal,

Le script optimisé est en ligne depuis deux ou trois jours. 

https://forum-hifi.fr/thread-41858.html

Pour Roon ne l'utilisant plus (plus d'abonnement) je n'en ai aucune idée malheureusement.
Le firewall de Windows, peut être?

[Alaindeloin]

Bonjour Dominique,
j'ai une question à propos du boot de mon pc, je n'ai jamais pu démarrer DRU en mode Uefi (que ce soit usb/ssd),boot secure désactivé, j'ai toujour le message inserer un disque bootable, il est uniquement demarrable en mode csm/ahci. 

Je pense que c'est la raison pour laquelle je ne peux pas utiliser le noyau RT (écran noir). mon pc date de 2012, c'est un Toshiba Qosmio x870/13. 

As-tu une idée de ce qui pose problème?
Merci d'avance pour ton retour.

[Le dom]

Bonjour Alain,
Il me faudrait un peu plus de précisions, tu essaies de démarrer quelle distribution?
Audiolinux? GentooPlayer? Fedora?