Cette page présente le paramétrage avancé d'une station audio-numérique professionnelle. Nous tâcherons de l'expliquer de manière simple et accessible, même pour un débutant. Nous ne reviendrons pas sur les paramétrages de base de Pipewire (déjà traités Ici - Configurer LinuxMint Zena pour la Mao) mais nous en affinerons certains, notamment l'attribution des coeurs du CPU à l'audio. Il fait suite à ces pages de discussion : ici.
Cet article se propose de répondre à la question suivante :
Nous disposons aujourd'hui de CPU à plusieurs cœur, est-il possible d'attribuer une fonction spécifique à certains de ces cœurs ?
Est il possible d'assigner des cœurs aux applications tels que Ardour, Muse, Qtractor etc... ?
La réponse est oui pour les deux questions.

Le matériel dont nous disposons

Le matériel dont nous disposons est le suivant :

1. PC de bureau, processeur Intel Core i7-9700T cadencé à 2 GHz, 8 cœurs, 16 Gb de RAM, disque SSD,
2. Carte son externe Behringer UMC1820, 8 entrées, 96 kHZ (testé aussi sur une UMC 404HD, 4 entrées, 192 kHz )
3. OS MxLinux 25.1 basé sur Debian Trixie, noyau Liquorix 6.15.2-1 installé.

Préambule : optimisation de la configuration audio : Enregistrement vs Post-production

La minimisation de la latence est impérative lors des phases d'enregistrement, spécifiquement lorsque vous devez vous synchroniser avec des pistes existantes (motifs rythmiques, bases musicales). Dans ce scénario de monitoring en temps réel, une latence élevée compromettrait la précision rythmique et la justesse de la prise.

Une fois les prises enregistrées, le flux de travail bascule vers la post-production (mixage, insertion d'effets et de greffons). Il est alors recommandé d'augmenter la taille du tampon (buffer size) à 128 ou 256 échantillons (à 48 kHz), offrant une latence respective d'environ 2,6 ms et 5,3 ms. Cette configuration accroît la marge de calcul du processeur, éliminant ainsi les risques de XRUN (dépassements de tampon) durant le mixage. Même en cas d'instabilité résiduelle (Xrun) lors de la lecture en temps réel, celle-ci n'affectera pas l'intégrité du fichier final lors du rendu (export), le calcul s'effectuant alors hors temps réel.

Quelques considérations préliminaires concernant la carte son

Concernant l'interface audio, il est inadéquat de vouloir absolument baser la configuration du système PC sur la résolution native de 24 bits/96 kHz spécifiée par le constructeur. Ce paramètre reflète uniquement les capacités de traitement interne du matériel, ex : UMC 1820, et n'établit aucune corrélation directe avec les performances d'échantillonnage exploitables par le système hôte c'est-à-dire votre PC.

Cela est d'autant plus pertinent que ce périphérique agit principalement comme un convertisseur transparent et un préamplificateur en entrée. Sa fonction n'est pas de traiter ou de modifier la résolution du flux, mais de transcrire fidèlement le signal analogique vers le domaine numérique (USB) selon le format demandé par l'hôte. La conversion Analogique/Numérique s'adapte donc dynamiquement à la fréquence d'échantillonnage définie par le PC, indépendamment de sa capacité maximale interne.

Prérequis et outils de diagnostic

Pour suivre ce tutoriel et analyser les performances du système, les utilitaires suivants sont requis :

• Éditeur de texte: Pour la modification des fichiers de configuration.
• pw-top : Outil de supervision dédié à PipeWire, permettant d'inspecter en temps réel les nœuds audio, les débits et les états de flux.
• htop : Moniteur de processus interactif pour visualiser la charge individuelle de chaque cœur du processeur et identifier les goulots d'étranglement lors du traitement audio.
• Cable : permettant de modifier le quantum (taille du tampon) et d'ajuster la résolution (fréquence d'échantillonnage) du système hôte.
• Raysession Interface graphique de routage permettant de reconfigurer la topologie audio
• Ardour : Station de travail audio numérique (DAW) utilisée comme charge de travail de référence pour évaluer la stabilité du système, la latence effective et le comportement global après l'application des réglages.

Évaluation des cœurs CPU à votre disposition

Pour cela, il suffit d'installer (s'il ne l'est pas), puis d'exécuter htop dans un terminal



Et vous obtenez quelque chose comme cela. Entouré de rouge la partie qui nous intéresse :


On peut observer deux choses : la première est que mon CPU dispose de 8 cœurs numéroté de 0 à 7, et que les zones 0 et 5, 6,7 sont au repos et que celles qui sont actives correspondent à mon navigateur web, gimp et kate. Comment le sait on ? Ce sont les logiciels que j'utilise présentement pour écrire cet article.
Concernant Pipewire, la tentation est grande de se dire qu'il serait judicieux d'attribuer 4 cœurs à pipewire. Oui... mais non. Après plusieurs essais 1 seul cœur suffit pour ma machine car il n'est jamais saturé.
Donc, je vais paramétrer le chargement de mon noyau pour qu'il réserve le cœur 0 que je vais attribuer, par la suite, à pipewire :

et remplacer la ligne suivante :

par celle-ci

Après l'enregistrement du fichier grub, ne pas oublier de faire :

Pour la signification de -isolcpus=0-2 nohz_full=0-2 rcu_nocbs=0-2, voir la note en bas de page

Si vous souhaitez attribuer plus de cœurs à pipewire, disons 3, la ligne s'écrira ainsi :

Il est judicieux après le grub-update de redémarrer l'ordinateur. Relancez htop et vous verrez que le coeur 0 ou 0,1,2 sont inutilisés. C'est le cas pour moi avec le coeur 0 que je vais attribuer à pipewire.(voir l'image plus haut).

Après cela, on suppose que pipewire est déjà configuré comme décris dans Configurer LinuxMint Zena... (voir plus haut)
Éditez le fichier suivant :

et ajoutez les lignes suivantes à la fin du fichier :


ou thread.cpu-affinity = [ 0,1,2 ] selon le cas un ou trois cœurs. (A nouveau, il s'avère que pour ma part un seul cœur suffit).

Maintenant, il faut surcharger les fichiers systemd qui concernent pipewire et wireplumber pour forcer pipewire à utiliser le cœur que nous lui avons réservé. Créons dans le .config des dossiers spécifiques :

ensuite créons un fichier :

dans lequel il faudra ajouter ces lignes

Même chose pour wireplumber :

puis

en collant exactement les même lignes.
On redémarre systemd et pipewire:


Après cela on peut vérifier que systemd à bien pris en compte ces modifications :

idem pour wireplumber.

Et maintenant.

Selon votre machine avec Cable, prenez soin d'observer quels sont les valeurs de quantum qui vous donne le moins de latence et sans Xrun. Pour ma part c'est 64/48000 pour 1.3 ms de latence. Testez cela avec Ardour.
Mon fichier de configuration dans ./config/pipewire... prend la forme suivante :


Ces valeurs finales sont valables pour la machine citée plus haut

Ce n'est pas tout

Prenons l'exemple de Ardour avec 4 pistes bien cossues et des plugins en veux tu en voilà. Les performances et les Xrun vont s'aligner. Pipewire n'est pas en cause. Mais vous risquez de voir le système partir en vrille. Là c'est un système de travail qui est en cause. En monitorant ce qu'il se passait, mon cœur 4 ou des fois 5 arrivait à saturation alors que le 6 et le 7 ne travaillait pas. Pourquoi ? Aucune idée. Mais la question qui s'est posée est la suivante :
Puis-je assigner des cœurs à un logiciel spécifique. La réponse est oui.
Par exemple pour Ardour il suffit de le lancer dans le terminal ainsi :

ce qui fait tourner Ardour sur 5 coeurs. Et c'est nettement mieux. Mais gardez en pour les processus systèmes. Cette procédure est valable quel que soit le logiciel utilisé.

Notes :

Allez sur le web et passez un truc youtube. Après avoir lancé pw-top dans un terminal. Mettez la vidéo sur pause et lancez Ardour. Oh surprise votre quantum reste bloqué au maximum que vous avez déterminé. 1024 par défaut ou 512 dans mon cas.
Donc voilà évitez de faire deux choses en même temps ! 😉

Concernant la commande grub, voici la signification pour ceux que cela intéresse :

1. isolcpus=0 : Empêche le planificateur standard d'envoyer des tâches sur ce cœurs.
2. nohz_full=0 : Désactive les ticks d'horloge sur ce cœurs pour éviter les interruptions périodiques inutiles.
3. rcu_nocbs=0 : Déplace les callbacks RCU hors de ce cœurs pour éviter les micro-coupures.

• !Liens et commentaires