Professional audio (Français)
Cet article décrit comment configurer votre système pour enregistrer en multipistes, mixer et lire de l'audio ainsi que l'utiliser pour synthétiser et générer des sons. Ces activités sont regrouppées sous le terme audio professionnel (pro audio) et nécessitent généralement des performances de faible latence.
La plupart des applications n'ont pas besoin de matériel aussi haut de gamme, que pour la production vidéo ou aux jeux vidéo. Pour plus d'informations, reportez-vous à Le bon ordinateur et le bon système pour l'audio digitale.
Pour commencer
Advanced Linux Sound Architecture (ALSA) fait partie du Linux kernel et est utilisé pour Pilotes et interface de bas niveau sur Arch Linux comme étant le serveur son par défaut. ALSA devrait fonctionner dès l'installation d'Arch Linux par défaut. Si ce n'est pas le cas, vous devez résoudre le problème avant d'aller plus loin.
La configuration du son est-elle correcte ?
$ speaker-test
- Voir ALSA pour un dépannage.
Un noyau Vanilla Arch Linux est suffisant pour un fonctionnement à faible latence dans la plupart des cas d'usage. #Optimisation de la configuration du système ne sera nécessaire que si vous rencontrez des décrochages audio (également appelés pépins) ou si vous avez besoin (ou envie) d'atteindre une latence ultra-faible.
Pour terminer avec les optimisations, ces opérations de latence ultra faible peuvent vous obliger à configurer un #Realtime kernel.
Bien que certains logiciels audio professionnels puissent fonctionner directement avec ALSA, la plupart des #Applications mentionnés plus loin utilisent JACK Audio Connection Kit ou clients JACK. Par conséquent, vous devrez installer et configurer l'un des serveur sonore disponibles qui sont décrits plus bas.
Choisir un serveur son
Le matériel sonore ne peut pas lire le son à partir de plus d'une application simultanément. Bien qu'ALSA peut théoriquement être configuré pour mixer le son de plusieures applications ceci est généralement délégué à un serveur son.
Comme ALSA seul ne peut pas atteindre de faibles latences facilement et ne peut pas synchroniser plusieurs applications audio, en commençant tous en même temps, au même tempo, etc., et qu'elle ne peut pas partager le flux audio entre les applications simplement en connectant tous ses clients ensemble, vous avez besoin non seulement d'un serveur son, mais de classe audio professionnel:
- PipeWire est un remplacement de JACK et PulseAudio pour la partie audio. Il prend aussi en charge le routage vidéo, mais ce n'est pas le sujet de cet article.
- Note Il n'est pas clair, si PipeWire doit être considéré comme un bon candidat pour un usage quotidien seulement et non pour des cas d'utilisations audio professionelle.
- JACK Audio Connection Kit (JACK) a été développé avec tous les besoins de l'audio professionnel et est utilisé dans le monde entier depuis de nombreuses années. Il est donc très stable et mature. La plupart des applications audio professionnelles sont écrites pour l'API JACK.
La configuration du serveur son dépend fortement du cas d'utilisation ainsi que du flux de travail et des capacités d'une certaine interaction avec les applications. JACK a été conçu pour partager l'audio entre les applications et accéder simultanément à un périphérique audio en fournissant l'exécution synchrone des clients tout en maintenant une faible latence constante. Son remplacement PipeWire fournit un serveur suffisant pour la plupart des cas d'utilisation.
Cette mise en page illustre un modèle de couche des configurations du serveur son à discuter :
#PipeWire seul #PipeWire client de JACK #JACK seul ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Applications │ │ Applications │ │ Applications │ ├──────────────┤ ├──────────────┤ ├──────────────┤ │ PipeWire │ │ PipeWire+JACK│ │ JACK │ ├──────────────┤ ├──────────────┤ ├──────────────┤ │ ALSA │ │ ALSA │ │ ALSA │ └──────────────┘ └──────────────┘ └──────────────┘
PipeWire seul
Le nouveau cadriciel PipeWire remplace JACK as well comme d'autres serveurs son par souci de simplicité. Ainsi, il est recommandé de commmencer avec PipeWire seul car ce montage mettant en œuvre un support pour Clients JACK en installant seulement pipewire-jack en utilisant le noyau vanilla Arch Linux.
Pour une utilisation audio pro, vous devez également sélectionner le profile Pro Audio en passant par pavucontrol, le mixer PulseAudio.
PipeWire client de JACK
PipeWire peut également être utilisé comme un client JACK en installant pipewire-jack-client. Cela est expliqué dans PipeWire#Run PipeWire on top of native JACK.
JACK seul
Le principe de versatilité d'archlinux vous permet d'employer JACK et le #Realtime kernel avec #Optimizing system configuration pour obtenir de faibles latences pour les cas d'utilisation avancés connus sous le nom de configuration JACK seul. L'utilisation de JACK comme seul serveur son nécessite un logiciel, destiné à l'interaction et à l'accès aux périphériques audio, pour fonctionner comme un client JACK.
Malheureusement, les applications de bureau populaires telles que Firefox ou la plupart des jeux ont abandonné la prise en charge de JACK ou ne l'ont jamais implémentée. Pour cette raison, cette configuration devrait être utilisée pour un système audio pro dédié où le logiciel non-JACK peut être négligé. Si vous avez toujours besoin d'utiliser un logiciel qui ne peut pas se connecter à JACK, reportez-vous à Professional audio/Examples#Advanced sound server setups après avoir suivi la configuration décrite ici. Avant d'installer et d'exécuter JACK, vous devez vous assurer qu'il peut accéder à votre appareil audio.
Est ce que PulseAudio ou autre chose s'accapare mon interface audio ?
$ lsof +c 0 /dev/snd/pcm* /dev/dsp*
ou
$ fuser -fv /dev/snd/pcm* /dev/dsp*
Si votre périphérique audio n'est pas répertorié, il peut être utilisé par PulseAudio (qui a probablement été installé comme dépendance d'une autre application). Arretez les applications qui jouent du son, si vous n'avez pas l'intention d'utiliser Professional audio/Examples#PulseAudio+JACK afin de faire en sorte que PulseAudio libère votre appareil audio.
Comme la version 1 de JACK est prévue pour être « lentement éliminée » [1], Ne supporte pas le Multiprocessing symétrique (SMP), ne propose pas l'intégration D-Bus et systemd, vous souhaitez utiliser la version 2 qui est disponible dans le paquet jack2. Si vous allez utiliser une IGU de contrôle JACK ou un service utilisateur systemd pour démarrer la baie de brassage audio, installez aussi jack2-dbus.
- Plus de détails dans JACK Audio Connection Kit#Comparison of JACK implementations
L'article sur JACK décrit un exemple de configuration basée sur une IGU et sur une shell comme point de référence pour votre propre scénario. Les valeurs de paramètres de JACK sont discutées en détail dans la section #JACK parameters et peut dépendre d'autres facteurs du système couverts par la section #Optimizing system configuration ci-dessous.
JACK parameters
L'objectif ici est de trouver la meilleure combinaison possible de taille de tampon et de nombre de tampons, étant donné le matériel que vous avez. Taille de tampon = 256 est un réglage sain. Pour les périphériques embarqués et USB, essayez Nombre de tampons = 3 avant de baisser les deux valeurs. Les valeurs couramment utilisées sont: 256/3, 256/2, 128/3, 128/2.
En outre, le taux d'échantillonnage doit correspondre au taux d'échantillonnage matériel. Pour vérifier quel échantillon et les débits de votre appareil prend en charge :
$ cat /proc/asound/card0/codec#0
Remplacer card0 and codec#0 par votre matériel. Vous serez à la recherche de Rates ou VRA dans Extended ID. Un taux d'échantillonnage commun à de nombreux appareils d'aujourd'hui est 48000 Hz. D'autres taux communs comprennent 44100 Hz, 96000 Hz et 192000 Hz.
Presque toujours, lorsque l'enregistrement ou le séquençage avec de l'équipement externe est concerné, realtime est un must. En outre, vous pouvez définir une priorité maximale (au moins 10 limites inférieures aux limites du système définies dans /etc/security/limits.d/99-realtime-privileges.conf; Le plus élevé est pour l'appareil lui-même).
Démarrez jack avec les options que vous venez de trouver :
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p128 -n2
qjackctl, cadenceAUR, patchageAUR et studio-controls-gitAUR peuvent tous être utilisés comme interface graphique utilisateur pour surveiller l'état de JACK et simplifier sa configuration.
- Plus de lecture : article de Linux Magazine (2006) pour la compréhension de base sur la recherche de paramètres JACK
Latency verification
JACK parameters are most significant for controlling the round-trip delay (RTD). In the context of this article that is the overall time it takes for an audio signal to be recorded, processed and played back. The next subsection deals with theoretical background on the sources of latency adding up to the RTD. If you are already familiar with that, you can go to #Measuring latency to verify your RTD or skip this section completely.
Latency sources
Consider a typical recording situation of a singer performance. The voice is being captured with a microphone as it propagates trough the air with the speed of sound. An analog-to-digital-conversion enables the electrical signal to be recorded by a computer for digital signal processing. Finally, a digital-to-analog conversion returns the signal to be played back at the singer's headphones for monitoring similar to stage monitor system usage.
In that voice recording situation there are five significant latency sources constructing the RTD and occuring in the following order:
- Sound propagation through the air from the mouth of the singer
- Analog-to-digital conversion
- Digital signal processing
- Digital-to-analog conversion
- Sound propagation through the air to the ear of the singer
The first and last latency source is hard to change as a particular distance is technically necessary to create an intended sound during recording or playback, respectively. Additionally, when using closer miking for capturing and headphones for monitoring both sound propagation latencies are typically within the range of a few microseconds which is not noticeable by humans. Thus, an objective for RTD minimization is to reduce the other sources of latency.
Conversion latency
In theory JACK maintains a constant low latency by using fixed values (frames, periods, sample rate) for sampling and buffering of audio to be converted analog-to-digital and vice versa. The latency occurring in the capturing process is described by the following equation:
- Lc = n / f
Lc: Capture latency in milliseconds (ms), n: Frames or buffer (multiples of 2, starting at 16), f: Sample rate in Hertz (Hz).
The playback latency is also employing the periods value:
- Lp = n * p / f
Lp: Playback latency in milliseconds (ms), n: Frames or buffer (multiples of 2, starting at 16), p: Periods, f: Sample rate in Hertz (Hz).
As already stated before, the capabilities of the audio interface define working combinations. You have to trial and error to find a setup. Sure, it is a trade-off between xrun prevention and achieving low latency, but recent audio interfaces can be used at high sample rates (up to 192 kHz) to deal with that requirement. The audio flux of JACK clients in the digital domain is about zero and thus, negligible for latency measurements [2].
- See FramesPeriods in the ALSA wiki for more information.
Measuring latency
Once you have set up #JACK parameters you might want to verify the RTD described above. For example, using a frames or buffer size of n = 128, a periods value of p = 2, and a sample rate of f = 48000 results in a capture latency of about Lc = 2,666... ms and a playback latency of about Lp = 5,333... ms summing up to a total round-trip delay of RTD = 8 ms.
The jack_delay utility by Fons Adriaensen measures RTD by emitting test tones out a playback channel and capturing them again at a capture channel for measuring the phase differences to estimate the round-trip time the signal has taken through the whole chain. Use an appropriate cable to connect an input and output channel of your audio device or put a speaker close to a microphone as described by JACK Latency tests.
For example, running jack_delay for a JACK-only setup using a cable connection between the ports playback_1 and capture_1 (the description may differ depending on your hardware) to close the loop, as well as the values discussed before yields the following insights:
$ jack_delay -O system:playback_1 -I system:capture_1
capture latency = 128
playback_latency = 256
Signal below threshold...
Signal below threshold...
Signal below threshold...
422.507 frames 8.802 ms total roundtrip latency
extra loopback latency: 38 frames
use 19 for the backend arguments -I and -O
422.507 frames 8.802 ms total roundtrip latency
extra loopback latency: 38 frames
use 19 for the backend arguments -I and -O
422.506 frames 8.802 ms total roundtrip latency
extra loopback latency: 38 frames
use 19 for the backend arguments -I and -O
422.507 frames 8.802 ms total roundtrip latency
extra loopback latency: 38 frames
use 19 for the backend arguments -I and -O
<output omitted>
As the output indicates further optimization of JACK can be done by using the parameters -I 19 and -O 19 to compensate for the reported extra loopback latency in the chain:
$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p128 -n2 -I19 -O19
- More details can be found in the Ardour Manual page about latency and latency compensation.
Realtime kernel
"Realtime" in the context of an operating system is defined that the results of a computation are available within a fixed period of time. Only in a broader sense does it mean "time running simultaneously with reality", for example, that a sound is produced immediately in response to musical user input. The latter is called "low latency" and its setup is one of the main goals of this article.
Since a while ago, the stock Linux kernel (with CONFIG_PREEMPT=y, default in Arch Linux vanilla kernel) has proven to be adequate for low latency operation. Latency in an operating system context is the time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running. Unfortunately, some device drivers can introduce higher latencies. So depending on your hardware, drivers, and requirements, you might want a kernel with hard realtime capabilities.
Pros and cons
The RT_PREEMPT patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. Most audio-specific Linux distributions ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.
Installation
Install either the linux-rt or linux-rt-lts package.
Compilation
If you are going to compile your own kernel as a realtime kernel, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in 1995.
- See HOWTO setup Linux with PREEMPT_RT properly for further general instructions.
In any way, you should also ensure that:
-
Timer Frequency is set to 1000Hz (
CONFIG_HZ_1000=y; if you do not do MIDI you can ignore this) -
APM is DISABLED (
CONFIG_APM=n; Troublesome with some hardware - default in x86_64)
If you truly want a slim system, we suggest you go your own way and deploy one with static /devs. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.
General issue(s) with (realtime) kernels:
- Hyperthreading (if you suspect, disable in UEFI settings)
Optimizing system configuration
- Optimisation is not a silver bullet—the effect hardly depends on your environment: while for some systems and setups a higher level of optimization is necessary, for most users this will not be the case. Try a standard setup with the vanilla Arch Linux kernel first; consider optimization if you are not satisfied with your current results only—e.g. if you believe your latencies or system stability could be improved.
- Be creative, try different settings.
- Measurement is the only source of trust—always measure before and after.
You may want to consider the following system optimizations:
- Setting the CPU frequency scaling governor to performance.
-
Configuring pam_limits (e.g. by installing realtime-privileges and adding your user to the
realtimegroup). - Using the
threadirqskernel parameter (consult [3] for reference) - enforced by default by the realtime kernel. - Using the realtime kernel.
- Add
noatimeto fstab (see Improving performance#Mount options). - Increasing the highest requested RTC interrupt frequency (default is 64 Hz) by running the following at boot:
# echo 2048 > /sys/class/rtc/rtc0/max_user_freq # echo 2048 > /proc/sys/dev/hpet/max-user-freq
- Reducing swappiness—swap frequency, set to
60by default—to e.g.10will make the system wait much longer before trying to swap to disk. More precisely, it makes the kernel to prefer keeping all applications in RAM instead of swapping background applications out. This can be done on the fly withsysctl vm.swappiness=10—see sysctl(8)—or set up permanently using a configuration file—see sysctl.d(5)—such as:
/etc/sysctl.d/90-swappiness.conf
vm.swappiness = 10
- Increasing the maximum watches on files (defaults to
524288) to e.g.600000, that inotify keeps track of for your user, can help with applications, that require many file handles (such as DAWs). This again can be done on the fly withsysctl fs.inotify.max_user_watches=600000or in a dedicated configuration file:
/etc/sysctl.d/90-max_user_watches.conf
fs.inotify.max_user_watches = 600000
You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).
$ setpci -v -d *:* latency_timer=b0 # setpci -v -s $SOUND_CARD_PCI_ID latency_timer=ff
E.g. SOUND_CARD_PCI_ID=03:00.0.
The SOUND_CARD_PCI_ID can be obtained like so:
$ lspci -nnd ::04xx
03:00.0 Multimedia audio controller [0401]: Creative Labs SB Audigy [1102:0004] (rev 05) 03:01.0 Multimedia audio controller [0401]: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller [1412:1724] (rev 01)
Tips and tricks
- Disable Wi-Fi and close any programs that do not need to be open when recording such as browsers. Many have reported disabling Wi-Fi has led to more reliable JACK performance.
- Some USB audio hardware is known not to work properly when plugged into USB 3 ports so try USB 2/1 ports instead.
- IRQ issues can occur and cause problems. An example is video hardware reserving the bus, causing needless interrupts in the system I/O path. See discussion at FFADO IRQ Priorities How-To. If you have a realtime or a recent kernel, you can use rtirq to adjust priorities of IRQ handling threads.
- Do not use the irqbalance daemon, or do so carefully [4].
- If you need to use multiple audio devices with JACK2, the alsa_in and alsa_out utilities can be used to have extra devices wrapped and show up as outputs in the JACK patchbay.
- Some daemons/processes can unexpectedly cause xruns. If you do not need it - kill it. No questions asked.
$ ls /var/run/daemons $ top # or htop, ps aux, whatever you are comfortable with $ killall -9 $processname # systemctl stop $daemonname
- If you are facing a lot of xruns especially with NVIDIA, disable your GPU throttling. This can be done via the card's control applet and for NVIDIA it is "prefer maximum performance" (thanks to a post in LAU by Frank Kober[5]).
Applications
Arch Linux provides the package group pro-audio holding all relevant (semi-) professional applications. All applications in the pro-audio package group are JACK clients. Also lv2-plugins, ladspa-plugins, dssi-plugins, vst-plugins and clap-plugins are subgroups of the pro-audio group.
An overview and brief information on some applications is found in List of applications/Multimedia#Audio. Especially the categories Digital audio workstations, Audio effects and Music trackers, as well as Audio synthesis environments and Sound generators provide examples of pro audio software for recording, mixing, mastering, and sound design. Other categories include Scorewriters, Audio editors, Audio converters, and DJ software.
Packages not (yet) in the official repositories can be found in proaudio. Browse the list of packages to find the application you need or request packaging of your desired applications via GitHub.
Hardware
The majority of sound cards and audio devices will work with no extra configuration or packages, simply set JACK to use the desired one.
This is not true for all devices, have a look at the Category:Sound, /Hardware (Français) as well as Envy24control#Supported cards for those special cases.
Get help
Mailing lists
- Arch Linux Pro-audio Discussion about real-time multimedia, including (semi-)pro audio and video.
- Linux Audio User The Linux pro-audio related mailing list with much traffic and a huge subscriber community of users and developers.
IRC
- #archlinux-proaudio - Arch Linux pro-audio channel
- #lau - General Linux Audio channel for users
- #jack - Development and support related to JACK audio system
- #lv2 - Development and support related to the LV2 plugin format
- #ardour - Discussion and support relating to the Ardour DAW
- #opensourcemusicians - Large general OSS musician discussion channel
See also
- Professional audio Comprehensive guide for a pro-audio setup based on Arch Linux
- lv2-plugins-aur-metaAUR — provides many LV2 plugins
- awesome-linuxaudio A list of software and resources for professional audio/video/live events production on the Linux platform
- Multimedia and Games / Arch Linux Forums
- Realtime The Linux Foundation wiki on the PREEMPT_RT patches