Noyau 2.6.X pour l`audio

Noyau 2.6.X pour l’audio
Willow75
Noyau 2.6.X pour l’audio
par Willow75
Traduit/adapté du site :
http://www.affenbande.org/~tapas/wiki/index.php
(http://www.affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio%20work%20on%20linux%202.6.x)
Table des matières
1. Latence....................................................................................................................................................1
1.1. Latence audio matériel ................................................................................................................1
1.2. Latence de synthé logiciel...........................................................................................................2
1.3. Latence du noyau ........................................................................................................................2
1.4. Latence PCI.................................................................................................................................2
1.5. Scheduling and Schedulers .........................................................................................................3
1.5.1. SCHED_OTHER............................................................................................................3
1.5.2. SCHED_FIFO ................................................................................................................4
1.5.3. SCHED_RR....................................................................................................................4
1.5.4. Choisir la classe de scheduler.........................................................................................4
1.6. Realtime Linux Security module ................................................................................................4
1.7. mlock...........................................................................................................................................5
2. Preemption .............................................................................................................................................6
2.1. Kernel preemption.......................................................................................................................6
2.2. Voluntary preemption (deprecated see Realtime preemption) ....................................................6
2.2.1. Instructions d’Installation...............................................................................................6
2.2.2. Trois points importants ...................................................................................................7
2.3. Realtime preemption .................................................................................................................10
2.3.1. Preemptible Kernel (Low-Latency Desktop)................................................................11
2.3.2. Complete Preemption (Real-Time) ..............................................................................13
3. JACK.....................................................................................................................................................14
3.1. Native POSIX Threads Library.................................................................................................14
3.2. tmpfs ou shmfs ..........................................................................................................................15
3.3. XRUNS (deprecated see realtime preemption).........................................................................16
4. Basse latence pour l’audio...................................................................................................................19
4.1. Obtenir une basse latence avec l’USB ......................................................................................19
5. Info sur le noyau 2.6.x provenant du site www.agnula.org ..............................................................20
5.1. Compiler votre noyau 2.6 realtime............................................................................................20
6. Résumé de mon noyau realtime..........................................................................................................23
iii
Chapitre 1. Latence
http://www.affenbande.org/~tapas/wiki/index.php
(http://www.affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio%20work%20on%20linux%202.6.x)
Il y a différents types de latences rencontrés dans une utilisation typique d’un environnement
informatique pour le traitement audionumérique. Je vais essayer de vous en faire un petit aperçu.
La latence correspond à un retard. Il y a deux façons de connaitre la rapidité d’un ordinateur pour
manipuler des donnés audio, par exemple, on peut utiliser un stream audio :
En sortie : combien de données peuvent être manipulées par seconde, peuvent être mesurées, en bytes
par seconde par exemple.
La latence : combien de temps il faut pour qu’un morceau de données soit disponible aprés que votre
ordinateur l’ai reçu (de même pour les morceaux suivants de données), temps mesuré en secondes.
1.1. Latence audio matériel
On suppose que la taille de la période est la même pour l’enregistrement et la lecture ; et que cette taille
soit égale à 2 périodes. C’est le cas le plus simple
•
Latence d’entrée : Habituellement une carte son aura un buffer d’enregistrement composé de deux
"périodes" se composant chacune de N frames. Une des deux périodes sera occupée par le matériel
alors un IRQ sera défini au temps t_1.
Le driver de la carte son informe l’application, qui attend l’audio, qu’une période est disponible pour
le traitement. La carte son continue de remplir d’autres périodes. La première frames de la période
"incoming" correspond au temp t_2 = t_1-(N/SAMPLERATE).
Ainsi il est possible d’appeler N/SAMPLERATE la "latence d’entrée" de la carte son. Il peut y avoir
éventuellement des latences additionnelles dues à des convertisseurs Digital/Analogique de la carte
son et de dsp. Mais l’application n’a aucune influence sur ces derniers.
•
Latence de sortie: C’est fondamentalement la même chose que pour la latence d’entrée. Une période
est remplie par l’application tandis que l’autre période est jouée par l’application. La carte défini un
IRQ à la fin de la période qui est jouée. Puis l’application remplit la période jouée avant.
Ici nous avons encore la latence N/SAMPLERATE. Et aussi la latence due aux convertisseurs.
1
Chapitre 1. Latence
•
Traitement de la latence : Quelques algorithmes de dsp introduisent la latence dans le flux audio pour
créer une moyenne de quelques frames, ou réaliser une FFT avec des tailles de fenêtre plus grandes
que la taille de période, par exemple.
•
Latence d’aller retour (Roundtrip latency) : C’est, dans le meilleur des cas, la latence d’entrée + la
latence de sortie. Mais aussitot qu’un traitement de latence est utilisé ceci doit être pris en
considération. Nous obtenons : latence d’entrée + latence de traitement + latence de sortie.
Selon l’ordre d’IRQ des périodes entrantes et sortantes une autre période de la valeur des frames doit
être ajoutée à la latence due au buffer.
1.2. Latence de synthé logiciel
On pourrait penser que pour un synthé logiciel, qui produit seulement un flux audio en réponse aux
événements entrants (Midi, oscillateur ou GUI), serait seulement influencé par la latence de sortie du
système. He bien non! :) ce n’est pas toujours vrai.
Un événement se produit au temps t. Au temps t, le synthé logiciel intervient au milieu de la période de
traitement p. La carte son joue la période antérieure p-1. L’événement entrant doit être programmé pour
intervenir à la période p+1.
Ainsi une latence typique de synthé logiciel est au moins équivalente à 2 fois la latence de sortie.
1.3. Latence du noyau
Cette latence correspond au temps d’utilisation du noyau pour informer une application audio de l’IRQ
de la carte son. Ce temps doit être très court et constant.
Imaginez une taille de période de 64 frames. À un taux d’échantillonages de 48000 hertz, cela signifie
qu’une interruption apparait toute les 64/48000 de sec soit 1.3ms. Par exemple si le noyau a besoin de 1
ms, il ne reste que 0.3 ms pour manipuler les données audio.
La manipulation des IRQ est très rapide, Le vrai problème est quand une autre partie du noyau est
éxécutée et qu’elle est non "préemptible" (déchargeable) pendant un long moment.
Les patchs Kernel Preemption, Voluntary Preemption et notamment realtime preemption essayent de
fractionner les longs "codepaths", ainsi la latence moyenne du noyau devient très petite.
2
Chapitre 1. Latence
1.4. Latence PCI
Le terme latence PCI correspond au temps pendant lequel le matériel garde le bus pour lui. Ainsi, plus la
latence PCI d’un dispositif est longue, plus grande sera la "largeur de bande de bus" obtenue et plus cela
interférera avec d’autres synchronisations de matériels.
Utilisez la commande "lspci - v" pour inspecter les latences PCI de vos dispositifs.
Maintenant si vous voulez que votre carte son soit le dispositif préféré de PCI, définissez alors sa latence
à 128. Ramenez les latences PCI de tous autres dispositifs PCI à quelque chose comme 64 ou 32.
Ma carte son a l’adresse de bus suivante :
0000:00:0d.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion
Audio Accelerator] (rev 01)
Pour définir la latence pci de ce matériel au maximum (248=FEh) j’utilise : setpci -s 0:0d.0
latency_timer=fe .
Si vous voulez plus d’info (en anglais), ou man lspci et man setpci
http://www.reric.net/linux/pci_latency.html
1.5. Scheduling and Schedulers
Linux 2.6.x a trois différentes classes d’établissement de programme (scheduling) :
1.5.1. SCHED_OTHER
Cette classe est utilisée pour des processus normaux w/o RT. La plupart des processus sur un poste
bureautique typique sont dans cette classe. Il y a une variété de schedulers disponibles pour cette classe.
•
original two-arrayed O(1) scheduler
•
Con Kolivas staircase scheduler
•
some single priority array schedulers
•
etc (il ya plusieurs schedulers pour le sous système d’entrée sortie
3
Chapitre 1. Latence
Ce qui est commun pour tous ces schedulers est qu’ils n’ont aucun impact sur les processus de la classe
SCHED_FIFO ou de la classe SCHED_RR. Aussi longtemps que vos tâches audio seront éxécutées par
la classe SCHED_FIFO, le choix du scheduler SCHED_OTHER n’aura aucun effet.
1.5.2. SCHED_FIFO
Cette classe est basée sur la priorité. Tous les processus utilisant SCHED_FIFO sont exécutés avant
n’importe quel processus SCHED_OTHER.
Si un thread SCHED_FIFO a une priorité statique plus élevée qu’un autre alors il obtient le cpu en
premier. SCHED_FIFO fonctionne sans timeslices. Ceci signifie qu’un processus de SCHED_FIFO
commencé, s’éxécutera jusqu’à ce qu’il renonce au cpu volontairement ou à cause d’un processus ayant
une priorité plus élevée.
1.5.3. SCHED_RR
Dans SCHED_RR, n’importe quel thread prioritaire élevé qui devient exécutable devient un thread de
faible priorité. Essentiellement le scheduler définit des files d’attente, une pour chaque niveau de priorité.
1.5.4. Choisir la classe de scheduler
Pour inspecter et défnir la classe de scheduler de certains processus il faut utiliser l’utilitaire chrt du
paquet schedutils.
Quelques applications peuvent, cependant, définir la classe scheduling pour leurs propres threads,
notamment jackd. Ils doivent être éxécutés en root ou doivent utiliser des capacités particulières,
realtime-lsm par exemple.
1.6. Realtime Linux Security module
Si vous voulez donner des droits temps réels aux processus non root vous devez d’abord télécharger ceci.
realtime-lsm (http://sourceforge.net/projects/realtime-lsm)
Ou si vous utilisez une debian tapez
4
Chapitre 1. Latence
apt-get install realtime-lsm realtime-lsm-source module-assistant
cd /usr/src/
tar jxvf realtime-lsm.tar.bz2
module-assistant build realtime-lsm
dpkg -i realtime-lsm-module-2.6*.deb
Ceci peut être utilisé pour donner certaines possibilités aux simples utilisateurs , groupes, ou même à
tous les utilisateurs.
On charge comme ceci : modprobe realtime gid=1002 . Pour tous les utilisateurs appartenant au groupe
1002 :
•
les processus lancés appartiennent à la classe SCHED_FIFO
•
les processus de mémoire "sont mlock et mlockall" pour empêcher les permutations
Si vous utilisez un système debian, votre utilisateur appartient probablement à un groupe appelé audio
avec le gid 29 donc tapez modprobe realtime gid=29.
Information pour les ex-utilisateurs de 2.4.x : N’utilisez pas jackstart. Il n’est pas nécessaire quand
realtime-lsm est installé. Lancé directement Jackd par l’intermédiaire de jackd - R ou de JACKControl...
1.7. mlock
"mlocker" un secteur de mémoire virtuelle signifie "bloquer" cette mémoire virtuelle dans la RAM
physique, de ce fait on s’assure qu’elle ne sera jamais permutée.
Un processus qui doit être éxécuté comme un processus Temps réel doit utiliser mlock pour s’assurer que
rien n’est permuté, ce qui aurait comme conséquence des latences énormes.
Seulement les processus avec les priviléges root peuvent utiliser mlock/mlockall. sauf si vous utilisez
relatime-lsm
5
Chapitre 2. Preemption
2.1. Kernel preemption
C’est une technique où certains codepaths dans le noyau peuvent être interrompus pour être précédés par
des paths prioritaires plus élevés.
Cette technique est trés différente de voluntary preemption. Dans le cas du kernel préemption, le
scheduler décide quel thread du noyau est éxécuté. Dans le cas de voluntary preemption, le thread du
noyau signale lui même qu’il veut utiliser le cpu.
Donc je conseille voluntary preemption ou encore mieux realtime preemption.
2.2. Voluntary preemption (deprecated see Realtime
preemption)
voici le lien pour télécharger le patch d’ingo
http://people.redhat.com/mingo/realtime-preempt/
La version la plus ancienne est le patch Real-Time Preemption - V0.2. Lisez l’annonce suivante (en
anglais).
http://lkml.org/lkml/2004/10/22/207
Les patchs d’Ingo sont basés sur l’ensemble de patch d’Andrew Morton, voici le lien.
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
Attention, les patchs VP sont encore en developpement et changent régulièrement, je mettrai à jour ces
pages quand ils seront plus stable donc pensez a vérifier sur le site lkml.org les annonces de ces patchs.
2.2.1. Instructions d’Installation
Téléchargez les sources du noyau et des patchs désirées et décompressez les dans le repertoire usr/src/,
ici exemple avec un 2.6.9
6
Chapitre 2. Preemption
tar xjf linux-2.6.9.tar.bz2
Allez dans le repertoire linux-2.6.9 et appliquez le patch 2.6.9-rc2
patch -p1 < /chemin/du/patch/patch-2.6.9-rc2
Faites la même chose pour le patch mm4
patch -p1 < /chemin/du/patch/2.6.9-rc2-mm4
Si vous n’avez pas de message d’erreur tapez
patch -p1 < /chemin/du/patch/realtime-preempt-2.6.9-rc2-mm4-S7
Activez voluntary preemption, kernel preemption, hardirq, softirq preemption, big kernel lock
preemption, et si vous en avez besoin preempt-timing et preempt-tracing stuff dans la config du noyau et
configurez le reste du noyau comme vous avez l’habitude de le faire.
Compilez et installez le.
2.2.2. Trois points importants
2.2.2.1. La partie Voluntary preemption
C’est une technique où les codepaths dans le noyau "donnent" le cpu volontairement à certaines taches,
on peut la comparer au traitement multitâche cooperatif.
Cela permet d’améliorer la latence, de longs codepaths peuvent être décomposés en plus petits, de ce fait
réduisant la latence du noyau. Il semble que cette technique est une bonne addition de kernel preemption
disponible dans les noyaux vanilla.
7
Chapitre 2. Preemption
Il y a un fichier dans /proc pour controler la préemption d’un noyau patché avec les patch VP d’Ingos.
Définissez /proc/sys/kernel/kernel_preemption et proc/sys/kernel/voluntary_preemption à 1. Utilisez ces
commandes :
echo 1 > /proc/sys/kernel/voluntary_preemption
echo 1 > /proc/sys/kernel/kernel_preemption
Avec des versions antérieures des patchs VP, /proc/sys/kernel/voluntary_preemption peut être défini à
des valeurs > 1. Si vous éxécutez un ancien patch, utilisez les valeurs :
0:
1:
2:
3:
off
more preemption + max_sectors_kb
more preemption + max_sectors_kb + redirect softirqs
more preemption + max_sectors_kb + redirect softirqs + redirect hardirqs
2.2.2.2. La partie threaded IRQ handlers
Pour activer threaded IRQ handlers, utilisez les commandes suivantes
echo 1 > /proc/sys/kernel/hardirq_preemption
echo 1 > /proc/sys/kernel/softirq_preemption
Quand threaded irq handlers est utlisé , chaque irq handler a une entrée dans /proc/irq
La commande suivante permet de montrer quels irqs handlers sont éxécutés threaded(1) ou
non-threaded(0). Exemple:
grep .
/proc/irq/*/*/threaded
Le résultat sur mon ordinateur donne ceci
8
Chapitre 2. Preemption
/proc/irq/10/eth0/threaded:1
/proc/irq/12/i8042/threaded:1
/proc/irq/14/ide0/threaded:1
/proc/irq/15/ide1/threaded:1
/proc/irq/1/i8042/threaded:1
/proc/irq/5/CS46XX/threaded:0
/proc/irq/8/rtc/threaded:0
Pour placer la valeur à 0 pour l’iRQ 5 et 8 j’ai utilisé les commandes suivantes :
/bin/echo 0 > /proc/irq/8/rtc/threaded
/bin/echo 0 > /proc/irq/5/CS46XX/threaded
Et si vous entrez ces lignes dans le fichier /etc/rc.local ou dans un autre script de démarrage,
assurez-vous que le module de la carte son soit réellement chargé avant.
En utilisant le programme chrt du paquet schedutils vous pouvez changer la priorité et la politique de
scheduling de certains IRQ handlers. Une configuration possible est de définir tous les threads, excepté la
carte son et rtc, SCHED_FIFO à une priorité de 10.
jackd est éxécuté avec une priorité temps réel de 20. De cette façon aucun irq handler ne peut acquérir la
carte son /jackd/rtc.
2.2.2.3. Contrôle des tailles de données maximum pour les bloc
d’interfaces
Dans /sys/block/hd*/queue/ il y a un fichier appelé max_sectors_kb qui peut être utilisé pour faire que le
code qui manipule les entrées-sorties du dispositif emploie de plus petits morceaux de données, cela
réduit le temps pris pour accomplir le transfert et réduit de ce fait la latence du noyau.
Cela semble bien fonctionner quand on défini cette commande à 16 pour les hd. Si vous avez des xruns
reliés à l’activité de vos disques, vous pourriez essayer ceci.
echo 16 > /sys/block/hda/queue/max_sectors_kb
9
Chapitre 2. Preemption
Pour vérifier ce qui est défini pour chacun de vos dispositifs de bloc, tapez la commande suivante :
grep . /sys/block/*/queue/max_sectors_kb
Si vous n’avez pas de dossier /sys, soyez sûr d’avoir un noyau compilé avec l’option
CONFIG_SYSFS=y. Ajoutez alors à /etc/fstab la ligne suivante :
sysfs
/sys
sysfs
defaults
0
0
Synchronisation de latence : Le patch voluntary preempt introduit également des mécanismes puissants
pour vérifier plus finement les latences existantes du noyau. Voir la page sur XRUN pour plus de détails.
2.3. Realtime preemption
Le patch realtime preemption est disponible ici
http://people.redhat.com/mingo/realtime-preempt/
Maintenant il vous faut patcher le kernel. Si vous ne vous sentez pas à l’aise avec cette opération, il y a
un script disponible ici
http://affenbande.org/~tapas/RP-patch-script
Ce script essaye de télécharger toutes les sources nessecaires et les patchs pour patcher le noyau avec le
patch realtime préemption + le patch realtime lsm (le script n’est pas toujours a jour, mais vous pouvez
facilement le modifier pour une version plus récente des patchs)
Choisir le modèle de préemption. Le patch Realtime préemption introduit de nouveaux modèles de
préemption qui tiennent compte des opérations basse latence.
Allez voir la section
Processor type and features
10
Chapitre 2. Preemption
du menu make menuconfig des sources du noyau, une nouvelle option est aparue
Preemption Mode
Elle offre 4 choix
No Forced Preemption (Server)
Voluntary Kernel Preemption (Desktop)
Preemptible Kernel (Low-Latency Desktop)
Complete Preemption (Real-Time)
Les options les plus intéressantes pour le travail audio basse latence avec linux sont "Preemptible Kernel
(Low-Latency Desktop)" et "Complete Preemption (Real-Time)"
2.3.1. Preemptible Kernel (Low-Latency Desktop)
C’est un arrangement approprié pour les personnes qui n’ont pas un besoin de latences vraiment basses.
En choisissant ce modèle de préemption, veillez à permettre également :
Thread Softirqs
and
Thread Hardirqs
Ce paramètre permet essentiellement que l’éxecution des irg soit soumise aux decisions du scheduler
(planificateur). Les Irq ne sont pas necessairement exécutés directement, mais plutôt reportés dans un
"handler thread". Cette "handler thread" fonctionne avec des privilèges realtime (voir la section
Scheduling and Schedulers).
11
Chapitre 2. Preemption
Les priorités de ces irq handler threads sont fixées autour de 50. Ainsi en assignant une priorité en temps
réel plus élevée à jackd nous sommes certains que les irq ne perturbent pas JACK.
Assurez vous aussi que
Old-Style Big Kernel Lock (NEW)
soit désactivé. Configurez le reste du noyau comme vous le souhaitez, compilez et rebootez. Maintenant
il faut unthreaded l’irq "handler thread" de votre carte son. Sur mon système j’utilise la commande
suivante:
/bin/echo 0 > /proc/irq/3/CS46XX/threaded
Cela fait que l’irq de la carte son est la seule interruption qui soit traitée immediatement. Tout les autres
IRQ sont reportés dans leurs handler threads respectifs. Pour découvrir quel irq utilise votre carte-son,
utilsez la commande :
cat /proc/interrupts
Voici le résutat sur mon système
~$ cat /proc/interrupts
CPU0
0: 357694670
1:
192527
2:
0
3:
3683355
5: 203367747
8:
12983156
10:
18757427
11:
652848
12:
3109504
14:
1693997
15:
3617940
NMI:
0
ERR:
600
XT-PIC
XT-PIC
XT-PIC
XT-PIC
XT-PIC
XT-PIC
XT-PIC
XT-PIC
XT-PIC
XT-PIC
XT-PIC
timer 0/94670
i8042 0/92527
cascade 0/0
CS46XX 0/83355 <--- my soundcard
ICE1712 0/67747 <--- another one :)
rtc 0/83156
eth0 0/57427
nvidia 0/52848
i8042 0/9504
ide0 0/93997
ide1 0/17940
12
Chapitre 2. Preemption
Il est important d’avoir un simple irq pour la carte son, parce qu’autrement d’autres dispositifs de cet irq
obtienent le même traitement prioritaire qui pourrait déranger l’exploitation de la carte-son.
Assurez-vous aussi d’exécuter jackd en temps réel avec une priorité d’au moins 60 (parce que les autres
irq handlres thread ont un priorité autour de 50 et nous voulons que JACK soit plus haut).
2.3.2. Complete Preemption (Real-Time)
En choisissant l’option complete preemption, vous ne devez pas spécifiquement permettre le threaded irq
handlers comme dans le preemption model.
La différence principale est qu’à cause de cela nous ne pouvons pas "unthreader" l’ird handler de notre
carte-son. Cela signifie que nous devons donner une très haute priorité à son irq handler thread.
Vous pouvez utiliser l’utilitaire chrt de la suite schedutils pour ceci
http://www.tech9.net/rml/schedutils/
Pour mettre la priorité de l’irq handler de la carte son à 99 (le plus haut possible), utilisez une commande
semblable à la suivante :
chrt -f -p 99 ‘pidof "IRQ 3"
13
Chapitre 3. JACK
3.1. Native POSIX Threads Library
Lisez la Faq du site de JACK pour des renseignements sur jackd et Native POSIX Threads Library libc.
Assurez-vous de la lire si vous utilisez un noyau 2.6.x ou 2.4.x avec le support NPTL patché.
Si vous obtenez des résultats absolument non satisfaisants avec un noyau 2.6.x, il y a de grandes chances
que vous ayez un problème avec Native POSIX Threads Library et que jackd se comporte bizarrement.
Il faut exporter la variable d’environnement LD_ASSUME_KERNEL et la définir à 2.4.22. Cela
empêchera libc d’utiliser NPTL.
Exécutez jackd comme cela :
LD_ASSUME_KERNEL=2.4.22 jackd -R -d alsa ....
Exécutez tous les clients comme :
LD_ASSUME_KERNEL=2.4.22 qjackctl
ou
LD_ASSUME_KERNEL=2.4.22 ardour
Pour vérifier que vous utilisez libc avec NPTL activé, utilisez la commande suivante (en fait vous
exécutez libc)
pnambic@sokoban:~> /lib/libc.so.6
GNU C Library 20040808 release version 2.3.4, by Roland McGrath et al.
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
14
Chapitre 3. JACK
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6).
Compiled on a Linux 2.6.7 system on 2004-08-12.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
Le mot-clé à chercher est "Native POSIX Threads Library", bien sûr. Et si cela n’apparait pas, utilisez la
commande suivante :
willow@debian:~$ getconf GNU_LIBPTHREAD_VERSION
NPTL 0.60
3.2. tmpfs ou shmfs
Jackd doit utiliser fifo pour communiquer avec les clients JACK. Ces fifos ne doivent pas être sur un hd
réel, mais plutôt dans un système de fichiers virtuel comme tmpfs. Avoir fifo sur un hd réel, peut
provoquer beaucoup de Xruns.
Jackd peut être configuré au moment de la compilation pour utiliser un certain répertoire pour ses fifos.
Le répertoire par défaut est /tmp.
Beaucoup de distributions installent le paquet jackd de façon à ce qu’elle utilise /dev/shm (contrôlez avec
mount, si c’est tmpfs ou shmfs de monter).
Si vous trouvez vos fichiers fifo de JACK dans /tmp et si /tmp est sur un hd ordinaire vous pouvez obtenir
des Xruns préoccupants. Ainsi montez tmpfs ou shmfs sur /tmp (sa taille est cependant limitée à votre
mémoire virtuelle). Vous pouvez aussi recompiler jackd à partir des sources et définir le montage tmpfs
ou shmfs de votre choix.
Les fichiers fifo ressemblent a ceci :
15
Chapitre 3. JACK
tapas@mango:~$ ls /dev/shm/ -l
total 0
prw-r--r-- 1 tapas tapas 0 Sep
prw-r--r-- 1 tapas tapas 0 Sep
prw-r--r-- 1 tapas tapas 0 Sep
srwxr-xr-x 1 tapas tapas 0 Sep
srwxr-xr-x 1 tapas tapas 0 Sep
24
24
24
24
24
02:08
02:08
01:55
01:55
01:55
jack-1000-ack-fifo-31582-0
jack-1000-ack-fifo-31582-1
jack-1000-ack-fifo-31582-2
jack_1000_0
jack_1000_ack_0
Pour vérifier que tmpfs ou shmfs est présent, utilisez ceci
tapas@mango:~$ mount|grep /dev/shm
tmpfs on /dev/shm type tmpfs (rw)
3.3. XRUNS (deprecated see realtime preemption)
ALSA a une option au moment de la compilation du noyau pour debuger les Xruns. Activez ALSA
debugging dans la config de votre noyau et recompilez les modules alsa.
Activez le Xrun debugging en utilisant les commandes suivantes :
echo 2 > /proc/asound/card0/pcm0p/xrun_debug
echo 2 > /proc/asound/card0/pcm0c/xrun_debug
Ceci suppose que votre carte son est la carte 0. Vous devriez maintenant voir les Xruns dans le fichier
/var/log/syslog. Il peut être pratique de rediriger ce fichier dans une console:
tail -f /var/log/syslog
Il y a aussi un patch preempt timing pour le patch O4 (voluntary preemption) disponible ici :
http://redhat.com/~mingo/voluntary-preempt/preempt-timing-on-2.6.8-rc3-O4.patch
16
Chapitre 3. JACK
Ce patch ajoute un fichier :
/proc/sys/kernel/preempt_thresh
Qui peut être utilisé pour créer un rapport sur n’importe quels chemins du noyau prennant un plus long
seuil en microsecondes. Quelque chose comme cela devrait donner de bons résultats :
echo 1000 > /proc/sys/kernel/preempt_thresh
Les rapports sont mis dans le fichier /var/log/syslog. Définissez à 0 pour désactiver ce service :
echo 0 > /proc/sys/kernel/preempt_thresh
Notes : Le code preempt timing est incorporé dans les VP patch versions O7 et suivant.
La version O7 des VP patchs introduit 2 nouveaux mécanismes de temps de latence :
1) Si preempt_thresh est définit à 0, le code preempt timing générera un rapport quand un nouveau
maximum de latence sera atteint. Ainsi il existe un nouveau fichier,
/proc/sys/kernel/preempt_max_latency
d’où la valeur de latence maximale actuelle atteinte peut être lue. Ce fichier est aussi modifiable pour
réinitialiser le code preempt timing.
2) Il y a aussi un nouveau fichier
/proc/sys/kernel/trace_enabled
17
Chapitre 3. JACK
qui activera le nouveau preempt trace code dans VP > O6 (on doit l’avoir activé dans la config du noyau.
Cette trace est plus détaillée que l’ancien rapport et celui ci peut toujours être lu à partir de :
/proc/latency_trace
AVERTISSEMENT
En activant xrun_debug et preempt timing vous allez probablement déclencher de faux preempt timing
rapport par les applications qui ont provoqué des xruns (chaque déclenchement d’un rapport xrun_debug
déclenche à son tour un rapport preempt timing).
Il y a aussi le danger que les rapports preempt timing déclenchent des Xruns (en utilisant des petits seuils
preempt). Donc soyez prudent.
18
Chapitre 4. Basse latence pour l’audio
La série des noyaux 2.6.x serait moins performante que la série 2.4.x avec les patchs lowlatency et/ou
preemptible appliqués. Pour certains, les performances sont satisfaisantes mais pour d’autres cela est
insuffisant. Particulièrement quand on travaille avec de très petites tailles de périodes comme 128 ou 64
frames pour les opérations en temps réel.
Ceci est vrai pour les noyaux 2.6.x vanilla (même avec le kernel préemption) mais cela n’est plus valable
pour les noyaux 2.6.x patchés avec les patchs "voluntary preemption" d’Ingo Molnars. Ces patchs sont
toujours en developpement mais permettent déja d’éxécuter jackd avec 2*128 frames et xrun libre, le
temps de latence pour 256 frames à un taux d’échantillonage de 48000hz est autour de 5.3ms.
Comme la série S des patchs VP, ils sont basés sur le mm kernel. Ceci signifie que vous exécutez
techniquement un kernel expérimental, mais cela fonctionne correctement dans la plupart des
configurations.
Il n’existe aucun noyau prépackagé avec les patchs VP, ainsi vous devez les contruire vous mêmes.
Veuillez être sur de ce que vous faites, en cas de doute au sujet des infos fournit sur ces pages, vérifiez
svp les annonces d’ingo sur lkml.org.
Si vous obtenez des résultats non satisfaisants avec un noyau 2.6.x, il y a une grande probabilité que ce
soit du a un probléme avec NPTL. lisez la page de Jackd & NPTL. Un autre problème connu est les
tmpfs .
Attention Les noyaux VP basés sur un 2.6.9-rc3-mm2 sont cassés (USB suibsystem principalement et
ACPI)
4.1. Obtenir une basse latence avec l’USB
Voir ce lien
http://www.affenbande.org/~tapas/wiki/index.php?USB%20Low%20Latency%20Success
19
Chapitre 5. Info sur le noyau 2.6.x provenant du
site www.agnula.org
Ces infos datent d’octobre 2004, depuis agnula a packagé un noyau 2.6.10-multimedia (voir sur les
serveurs de paquets d’agnula)
Comme n’importe quelle distribution Debian récente, DeMuDi peut aussi utiliser un noyau 2.6. Le
paquet debian noyau 2.6 peut facilement être installé. Cependant, pour des users normaux (non hackers)
on recommande les noyaux 2.4 pour la production audio. Les performances en temps réel du noyau 2.4
DeMuDi sont assez bonnes et le noyau est stable.
Pour améliorer la latence et tenir compte de l’exploitation en temps réel, le noyau 2.6 doit être patché. Le
dernier noyau est le 2.6.9 et la performance audio n’est pas aussi bonne que pour le noyau 2.4 DeMuDi.
Mais le développement va à une allure rapide et des patches sont disponibles.
Pour l’instant, la combinaison des patchs mm et des patchs realtime est le meilleur choix. Ces patchs
changent chaque jour, surtout l’amélioration, mais aussi avec des bugs de temps en temps, donc moins de
stabilité. Vous êtes avertis.
5.1. Compiler votre noyau 2.6 realtime
Nous allons donc patcher les sources du kernel avec le patch mm et le patch realtime. Notez que cela
n’incluera pas les patchs debian, ainsi il pourrait y avoir quelques problèmes de compatibilité avec votre
installation debian. Cependant, pour la plupart des personnes cela fontionne trés bien.
1. Pour compiler des noyaux nous utiliserons la méthode debian, c’est plus simple d’utiliser des paquets
.deb, installez ces outils :
apt-get install fakeroot kernel-package
Obtenez, avec wget, le noyau de votre mirroir kernel.org favori
http://mirror.switch.ch/ftp/mirror/kernel/linux/kernel/v2.6/
(http://mirror.switch.ch/ftp/mirror/kernel/linux/kernel/v2.6/)
tapez
20
Chapitre 5. Info sur le noyau 2.6.x provenant du site www.agnula.org
cd /usr/src
tar jxvf linux-2.6.9.tar.bz2
ln -s linux-2.6.9 linux
Obtenez le patch mm
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/
(http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9/2.6.9-mm1/)
Tapez
cd linux
bzip2 -dc ../2.6.9-mm1.bz2 | patch -p1
cd ..
Obtenez le patch reatime preempt d’Ingo Molnars
http://people.redhat.com/mingo/realtime-preempt/ (http://people.redhat.com/mingo/realtime-preempt/)
Tapez
patch -p0 < realtime-preempt-2.6.9-mm1-V*
Configurez le noyau. Pour faire un vrai paquet debian, il faut éditer EXTRAVERSION dans le fichier
Makefile pour ne pas avoir de majuscule. Tapez
vi +/EXTRAVERSION Makefile
Maintenant compilez votre noyau, cela peut être long. tapez
time fakeroot make-kpkg --initrd kernel_image
21
Chapitre 5. Info sur le noyau 2.6.x provenant du site www.agnula.org
Vous pouvez avoir des messages concernant cramfs et initrd, mais cela n’est pas problèmatique. Par
contre l’auteur a eu un problème avec le module de drm-gamma, il l’a désactivé.
Installez le nouveau noyau et rebootez
dpkg -i ../kernel-image-2.6.9-mm1-rt-v0.5.14_10.00.Custom_i386.deb
reboot
Si votre noyau ne démarre pas, vérifiez les options. Si tout se passe bien, il faut maintenant installer le
module realtime (voir chapitre 1.6 realtime security module)
22
Chapitre 6. Résumé de mon noyau realtime
A venir ....
23