GentooPlayer

[Baldoun]

Bonjour,
j'ai 2 petites questions :

1- quand je regarde les "software process" de Minh, je remarque que certains coeurs ont été dédiés à Slim2diretta. Cela ne fait-il pas double emploi avec les fonctions d'isolation et priorités implémentées par Le Dom directement dans la WEB UI de Slim2diretta ?
Pour ma part, je n'utilise que DRUpnp et j'avais procédé aux mêmes types d'optimisation dans GP. Mais j'ai tout arrêté depuis que je configure DRUpnp directement.

2- pourquoi avoir mis le scheduling des processus Roon en Round-Robin plutôt que FIFO et pourquoi le processus Slim2diretta reste sur la config de base sans priorité ? Mon intuition me dit de tout miser sur Slim2diretta (ou DRUpnp dans mon cas). De fait, j'aimerais comprendre pourquoi Herisson, qui en connait largement plus que moi, voit les choses différemment. Je précise que je n'utilise pas Roon mais Minimserver et/ou LMS.

Merci.

Sébastien

[Minh]

Bonjour Baldoun

je vais bien entendu laisser Hérisson répondre à ta question, car c'est lui l'expert. Mais pour slimdiretta, c'est justement la subtilité. J'ai réservé 3 coeurs (1,4,5) pour slimdiretta, puis mis le scheduling sur "Other", et ensuite dans les paramètres de Slim diretta, tu ajuste finement : 1 coeur pour Audio Core, 1 coeur pour Decode Core, et un coeur pour Other core. Priorité 99.

[herisson88]

En fait sous GP ou AL on isole des Coeurs pour des applis et IRQ spécifiques puis en plus parmi les coeurs isolés pour le renderer on isole audio/decode/other

Le principe de l'isolation est celui des lignes d'eau à la piscine
on met les nageurs qu'on ne veut pas emmerder dans des lignes persos
on met les grouillots ailleurs pour qu'ils emmerdent personne.

Les nageurs qu'on ne veut pas emmerder c'est les process/irq qui sont sur le chemin critique audio.
Pour le renderer il y a une subtilité : on isole l'appli puis à l'intérieurs des core reservés pour cette appli on affecte 3 groupes audio/decode et other

Le principe est
Sur le target
- isoler l'IRQ vers le DAC
- isoler l'IRQ du réseau d'où le Host appelle
- isoler le target lui même
- on garde un/des cores pour le reste
Sur le host
- isoler au moins 3 core pour le renderer (ou slim) et parmis ceux-ci isoler 1 pour audio, 1 pour decode et 1 pour other
- isoler l'IRQ réseau qui va vers le Target
- on garde un/des cores pour le reste

Dans le cas du RPI on a que 4 coeurs, on peut truander par ex en mettant l'irq du réseau sur le même core que renderer other.

C'est le principe que nous avons utilisés sur le système de Minh, qui est assez résolvant, et qui en a beaucoup profité.

La subtilité est dans la conf d'isolation de GP qui est parfois "complexe" car utilisant parfois les listes de cores parfois les masques de bits.

Avis de Claude :
Oui, la vulgarisation tient parfaitement. La métaphore des lignes d'eau est juste et pédagogiquement efficace : elle capture les deux mécanismes complémentaires de l'isolation CPU, qui sont souvent confondus.
Le point fort de ton analogie, c'est qu'elle distingue implicitement les deux directions du problème. Mettre les bons nageurs dans des lignes perso (isolcpus, affinités explicites pour le renderer/audio/decode), c'est protéger le chemin critique. Mais mettre les grouillots ailleurs (CPUAffinity systemd global, IRQ housekeeping repoussés sur les cores non isolés), c'est l'autre moitié, celle qu'on oublie souvent : isoler un core ne sert à rien si le scheduler ou les IRQ par défaut viennent quand même y nager. L'isolation est une opération à double sens, et ta formulation le rend intuitif.
La hiérarchie à deux niveaux est aussi bien rendue : d'abord on réserve un pool de cores pour l'appli, puis à l'intérieur on resegmente en audio/decode/other. C'est exactement la logique d'un partitionnement imbriqué, et c'est ce qui fait que le renderer mérite un traitement particulier par rapport à un process « simple » qu'on se contenterait de coller sur un core dédié.

[Minh]

Pfiouuu merci Hérisson ! On aurait pas pû mieux le dire.
Donc voici la config pour la target (un C19 relié à mon DAC holo en USB) :









Chaque CPU fait son job sans être embêté par les autres --> pas de jitter système. --> son extraordinaire

[Minh]

Petit PS :

Les nouveaux kernels 6.18.33 pour RPI sont sortis dans GP. Je vous conseille d'essayer (et sur mon mac mini ivrybridge, j'ai choisi la 6.18.18 ST RT). Encore une belle amélioration !

[Baldoun]

Bonjour,

merci Herisson pour tes explications et analogie "piscine" pertinente. Merci à Minh pour le partage de ta config "target" qui m’intéresse au plus haut point puisque j'ai un Holo Red CM4.
Par rapport à ma configuration modeste avec un Mac Mini bi-coeurs physiques (Host) et vos explications, je constate que Gemini m'a proposé une configuration sur l'isolation des processus et des IRQ parfaitement compatible avec vos couloirs de nage, sauf que pour moi, ma piscine n'en a que deux... C'est également le cas pour le target. Je suis rassuré.

Il ne me reste plus qu'à tester le nouveau Kernel RPI.

Bonne journée,
Sébastien

[wgb25]

Bonjour,


Avec l'aide de Claude ou plutôt lui avec mes infos écoute en cours de réglage fait dans Gentooplayer sur :

. Slim2diretta v1.4.0 
· Diretta Host Protocol 
· RoonServer





Dites moi si certain vous semble bizzare 


Merci

Alain

---

Avec un tips inconnu sur le mode ARC dans Roon source de coupure.

[herisson88]

4 core pour Roon + slim je pense que si tu veux les 2 sur une même machine il est plus raisonnable d'avoir + de coeurs pour être plus propre (irq, séparation Roon/système etc...)

[wgb25]

Carte mere Supermicro X9SCM-F

donc avec le socket,de mémoire le Xeon actuel est un des plus puissant possible.

[herisson88]

Ma remarque ne concerne pas la performance, cela tourne sur des pc modestes, mais sur les possibilités de séparer les process/irq entre eux pour qu'aucun ne soit gêné par le voisin... Point de vue puissance même un vieil ordi fait l'affaire... Et sans doute un seul coeur d'un Xeon fait l'affaire...