Chargement...
 
[Voir/Cacher menus de gauche]
[Voir/Cacher menus de droite]


La latence est un délai entre une action et son effet, dans le monde audio c'est le temps qui s'écoule entre une action qui produit du son et la perception de ce son par l'auditeur.

Un bon exemple de latence audio est le temps qui s'écoule entre le moment où nous voyons un éclair et celui où nous entendons le bruit du tonnerre.

Dans certains cas, il peut être utile de connaître la latence de son système audio.

Cette documentation assez technique a deux buts :
  • expliquer ce qu'est la basse latence,
  • optimiser votre système GNU/Linux pour réduire sa latence.



L'importance de la latence


La latence a moins d'importance que ce que pensent la plupart des gens. Effectivement, une très basse latence n'est réellement nécessaire que dans quelques situations seulement. Atteindre cette très basse latence requière une réponse très rapide de la part de l'ordinateur.

Quelques exemples qui viennent rapidement à l'esprit sont :

  • Jouer des instruments virtuels : un grand délai entre l'appui d'une touche et le son que l'instrument produit mettra la plupart des instrumentistes en dehors du tempo,
  • monitoring audio logiciel : si un chanteur entend sa propre voix suivant deux chemins différents, les os de sa tête et un casque, des latences importantes peuvent être dérangeantes,
  • effets live : ce cas est similaire à celui de jouer des instruments virtuels. À la place d'instruments ou de synthétiseurs virtuels, nous avons des instruments réels et un traitement numérique des effets sonores. Une très faible latence est importante quand nous utilisons l'ordinateur comme un rack d'effets (par exemple pour une guitare électrique) - une synchronisation précise peut aussi s'avérer importante si vous déclenchez manuellement des effets sonores du genre delays,
  • mixage live : certains ingénieurs du son utilisent un ordinateur pour mixer des performances live. Grossièrement, c'est une combinaison des éléments suivants : des moniteurs sur la scène, du traitement de signal pour les effets et l'égalisation. C'est effectivement plus délicat car nous ne voulons pas seulement une très faible latence (l'audio ne devrait pas accuser trop de retard par rapport à la performance), mais aussi une faible latence exacte (instabilité minimale) pour les lignes à retard entre les hauts parleurs avants et arrières.

Dans beaucoup d'autres cas (tels que playback, enregistrement, doublage, etc...) la latence n'est pas très importante ou peut être compensée.

Il faut savoir que l'oreille humaine ne perçoit la latence qu'à partir de 20 à 25 ms. Descendre en deçà, pour débuter, n'est donc pas essentiel. Cela pourra devenir plus important par la suite en cas d'utilisation MAO plus poussée.


Sources de latence


De nombreux facteurs contribuent à la latence totale d'un système. Parmi les plus importants, nous avons :


1. Le temps de propagation du son dans l'air


Le son est une perturbation mécanique d'un fluide, l'air, qui voyage à une vitesse relativement lente : environ 340 m/s. Ainsi :
  • Votre guitare ou votre piano acoustique a une latence d'environ 1 à 2 ms en raison du temps de propagation du son entre votre instrument et vos oreilles.
  • Si vous êtes loin du chanteur dans une grande salle de concert, le son va vous arriver plus rapidement à vos oreilles par le haut-parleur le plus proche que directement depuis la scène. Du coup vous allez entendre le son réel comme un écho du son amplifié.

Règle de calcul

Un rapide calcul pour évaluer la latence : chaque milliseconde ajoutée correspond à un pied (mesure anglo-saxone) entre vous et l'émetteur du son.
Donc 10ms de latence = 10 pieds de latence = 3 mètres. Cette qualité de latence (10ms) est bien. C'est comme si vous étiez à 3 mètre d'un ampli.
Par contre, 64ms correspondent à un peu plus de 20 mètres (64/3 = 21.33333...). C'est comme si vous étiez de l'autre côté d'un terrain de basket, et cela s'entend frown



2. Conversion numérique-analogique et analogique-numérique


Les signaux électriques voyagent très rapidement et leur temps de propagation est négligeable dans ce contexte.
Les conversions entre les domaines analogiques et numériques prennent un temps comparativement long pour être exécutées, ainsi leur contribution à la latence totale peut être considérable.
Des convertisseurs rapides sont un des facteurs qui différencient une interface audio de qualité d'une interface bon marché (à côté d'autres caractéristiques comme un faible bruit, une faible distorsion, etc).


3. Traitement du signal numérique


Les processeurs numériques ont tendance à traiter l'audio en gros morceaux, et la taille de ces gros morceaux dépend des besoins de l'algorithme utilisé ainsi que de considérations de coût et de performance. Ceci est généralement la cause principale de latence quand vous utilisez un ordinateur et une de celles que vous pouvez essayer de prédire et d'optimiser.


4. Architecture des entrées/sorties de l'ordinateur


Un ordinateur est généralement un processeur à usage général, pas un processeur audio numérique. Ceci implique que vos données audio doivent sauter un grand nombre de barrières sur leur chemin depuis l'extérieur du processeur ainsi que sur le chemin inverse. Dans ce processus, elles sont en concurrence avec les autres parties du système pour les mêmes ressources (temps CPU, bande passante du bus, etc...). Grâce aux efforts combinés des développeurs du noyau, du driver audio et de JACK, vous êtes en position de pouvoir optimiser votre système pour la tâche du traitement de l'audio numérique. Mais n'espérez pas de miracle. Vous pouvez aussi utiliser votre ordinateur pour écrire des documents, surfer sur internet... La polyvalence a un coût.

Beaucoup de distributions GNU/Linux modernes incluent un noyau très basse latence, appelé souvent realtime ou noyau temps-réel. Ces noyaux sont installables avec les gestionnaires de paquets et identifiés par le suffixe 'rt' dans leur nom. Ils permettent de travailler avec des performances importantes en MAO. Il est conseillé d'essayer un de ces noyaux officiels avant de se lancer dans la compilation du noyau (uniquement si vous cherchez une utilisation extrêmement poussée).

La latence dans votre ordinateur


Dans un environnement informatique, de nombreux composants sont utilisés et génèrent chacun un peu de latence. La latence de l'ensemble provoque un retard nécessaire au traitement audio numérique.

Il est facile de calculer la rapidité d'un ordinateur pour manipuler des données audio, par exemple en comptant le temps écoulé depuis l'appui sur la touche d'un clavier MIDI et la sortie du son correspondant sur les haut-parleurs.


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 tampon d'enregistrement composé de deux "périodes" se composant chacune de N échantillons. Une des deux périodes sera occupée par le matériel alors un IRQ sera défini au temps t_1.
Le pilote 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. Le premier échantillon de la période "incoming" correspond au temps t_2 = t_1-(N/fréquence d’échantillonnage).

Ainsi il est possible d'appeler N/fréquence d’échantillonnage la "latence d'entrée" de la carte son. Il peut y avoir éventuellement des latences additionnelles dues à des convertisseurs numérique/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/fréquence d’échantillonnage. Et aussi la latence due aux convertisseurs.
  • 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)Image : C'est, dans le meilleur des cas, la latence d'entrée + la latence de sortie. Mais aussitôt 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 échantillons doit être ajoutée à la latence due au tampon.

vous pouvez mesurer la latence de votre carte son avec l'outil jdelay


2. Latence de synthétiseur 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. Hé 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.


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 échantillons. À un taux d'échantillonnages de 48000 hertz, cela signifie qu'une interruption apparaît 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 exé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.


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

Pour plus d'infos, voir la page dédiée :
  > Tuto Réduire la latence des périphériques PCI


5. Planification et planificateurs


Linux 2.6.x a trois différentes classes d'établissement de programme (scheduling Image ) :

5.1. SCHED_OTHER


Cette classe est utilisée pour des processus normaux non RT. La plupart des processus sur un poste bureautique typique sont dans cette classe. Il y a une variété de planificateurs (schedulers Image ) disponibles pour cette classe.

  • original two-arrayed O(1) scheduler
  • Con Kolivas staircase scheduler
  • some single priority array schedulers
  • etc (il y a plusieurs planificateurs pour le sous système d'entrée sortie)

Tous ces planificateurs n'ont aucun impact sur les processus de la classe SCHED_FIFO ou de la classe SCHED_RR. Autrement dit, aussi longtemps que vos tâches audio seront exécutées par la classe SCHED_FIFO, le choix du planificateur SCHED_OTHER n'aura aucun effet.

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 du temps processeur en premier. SCHED_FIFO fonctionne sans tranches de temps (timeslices Image ). Ceci signifie qu'un processus de SCHED_FIFO commencé, s'exécutera jusqu'à ce qu'il renonce au processeur volontairement ou à cause d'un processus ayant une priorité plus élevée.

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 planificateur définit des files d'attente, une pour chaque niveau de priorité.

5.4. Choisir la classe de planificateur


Pour inspecter et définir la classe de planificateur de certains processus il faut utiliser l'utilitaire 'chrt' du paquet 'schedutils'.

Quelques applications peuvent, cependant, définir la classe de planificateurs pour leurs propres fils (threads Image ), notamment 'jackd'. Ils doivent être exécutés en root ou doivent utiliser des capacités particulières, 'realtime-lsm' par exemple.


6. Realtime Linux Security module


Si vous voulez donner des droits temps réels aux processus non root vous devez d'abord installer le paquet 'realtime-lsm'.
Si vous utilisez debian tapez :
$ 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.

Pour charger le module pour tous les utilisateurs appartenant au groupe 1002, procédez comme ceci :
$ modprobe realtime gid=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 debian, votre utilisateur appartient probablement à un groupe appelé audio avec le gid 29. La commande à utiliser deviendra donc :
$ 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...


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 exé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.



1. Preemption


1.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 exé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.

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

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 développement 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.


1.2. Instructions d'installation


Téléchargez les sources du noyau et des patchs désirées et décompressez les dans le répertoire usr/src/, ici exemple avec un 2.6.9

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 configuration du noyau et configurez le reste du noyau comme vous avez l'habitude de le faire.

Compilez et installez le.


1.3. Trois points importants


1.3.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 coopératif.

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.

Il y a un fichier dans /proc pour contrôler 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 exécutez un ancien patch, utilisez les valeurs :

0: off
1: more preemption + max_sectors_kb
2: more preemption + max_sectors_kb + redirect softirqs
3: more preemption + max_sectors_kb + redirect softirqs + redirect hardirqs


1.3.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 utilisé , chaque irq handler a une entrée dans /proc/irq

La commande suivante permet de montrer quels irqs handlers sont exécutés threaded(1) ou non-threaded(0). Exemple:

grep . /proc/irq/*/*/threaded

Le résultat sur mon ordinateur donne ceci

/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 exé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.


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

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.


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

du menu make menuconfig des sources du noyau, une nouvelle option est apparue

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)"


1.4.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'exécution des irg soit soumise aux décisions du scheduler (planificateur). Les Irq ne sont pas nécessairement 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).

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 immédiatement. 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 XT-PIC timer 0/94670
1: 192527 XT-PIC i8042 0/92527
2: 0 XT-PIC cascade 0/0
3: 3683355 XT-PIC CS46XX 0/83355 <--- my soundcard
5: 203367747 XT-PIC ICE1712 0/67747 <--- another one :-)
8: 12983156 XT-PIC rtc 0/83156
10: 18757427 XT-PIC eth0 0/57427
11: 652848 XT-PIC nvidia 0/52848
12: 3109504 XT-PIC i8042 0/9504
14: 1693997 XT-PIC ide0 0/93997
15: 3617940 XT-PIC ide1 0/17940
NMI: 0
ERR: 600

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


1.4.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"



2. JACK


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


2.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 :

tapas@mango:~$ ls /dev/shm/ -l
total 0
prw-r--r-- 1 tapas tapas 0 Sep 24 02:08 jack-1000-ack-fifo-31582-0


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

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

  1. Il y a aussi un nouveau fichier

/proc/sys/kernel/trace_enabled

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.
prw-r--r-- 1 tapas tapas 0 Sep 24 02:08 jack-1000-ack-fifo-31582-1
prw-r--r-- 1 tapas tapas 0 Sep 24 01:55 jack-1000-ack-fifo-31582-2
srwxr-xr-x 1 tapas tapas 0 Sep 24 01:55 jack_1000_0
srwxr-xr-x 1 tapas tapas 0 Sep 24 01:55 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. 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 développement mais permettent déjà d'exécuter jackd avec 2*128 frames et xrun libre, le temps de latence pour 256 frames à un taux d'échantillonnage 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 construire 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)


3.1. Obtenir une basse latence avec l'USB


Voir le paragraphe "USB" de la page QJackctl - configuration.


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


4.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 fonctionne 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/

tapez

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/

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/

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

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)

Liens et commentaires

Page en partie traduite par willow75 a partir de https://web.archive.org/web/20051217052112/http://tapas.affenbande.org/?page_id=3 (le site n'existe plus le 09/08/2022, lien vers une archive).

  • Mesure de la latence aller-retour avec jack_delay : voir le tuto sur la page jdelay.
Voir aussi :


[+]

Documentation [Afficher / Cacher]

Faire un don
[Afficher / Cacher]

Connexion
[Afficher / Cacher]


Mégaphone [Afficher / Cacher]

calixtus06, 14:33, jeu. 28 mars 2024: Bonjour et bienvenue à b.vl :-)
calixtus06, 09:30, mer. 27 mars 2024: Bonjour et bienvenue à Noar :-)
olinuxx, 18:50, lun. 25 mars 2024: Bonjour et bienvenue à Ted Demore cool
olinuxx, 17:52, dim. 24 mars 2024: Bonjour et bienvenue à Noitavon cool
calixtus06, 11:07, jeu. 21 mars 2024: Bonjour et bienvenue à obds, ceric :-)
obds, 16:12, mar. 19 mars 2024: Cet édito est juste parfait. Trop beau !
olinuxx, 11:48, ven. 15 mars 2024: Bonjour et bienvenue à Jerry cool
calixtus06, 18:03, mer. 13 mars 2024: Bonjour et bienvenue à tanguero :-)
olinuxx, 11:01, dim. 10 mars 2024: Bonjour et bienvenue à lolo cool
bda, 16:59, sam. 09 mars 2024: Chapeau pour l'édito. Vous êtes au top les gars :-)
allany, 07:20, jeu. 07 mars 2024: Ça ne fait jamais de mal, c'est l'éditorial ! [Lien]
olinuxx, 19:52, mer. 06 mars 2024: Bonjour et bienvenue à TrkNrk cool