Professional audio (Français)

État de la traduction:
Cet article est la version francophone de
Professional audio
. Date de la dernière traduction: 2022-08-19. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
/Development (Français)
/Examples (Français)
/Hardware (Français)
JACK
PipeWire
Sound system
Realtime kernel
envy24control
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
.
Tip
Si vous cherchez un guide sur la façon de faire de la musique sur
GNU/Linux
, recherchez les forums
LinuxMusicians
.
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.
Tip
Cependant, si vous êtes nouveau sur Arch Linux, que vous venez de terminer le
Guide d'installation
et que vous ne pouvez pas attendre pour commencer à faire de la musique,
installer
le
groupe de paquets
pro-audio
ainsi que
realtime-generic-setup
AUR
et redémarrez. Reportez-vous à la section [[#PipeWire-only]|PipeWire seul]] pour une configuration rapide et trouvez votre
#Applications
pour la production musicale et sonore.
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.
Paramètres JACK
Note
Le guide suivant devrait vous aider dans la recherche des meilleures valeurs de paramètres possibles pour exécuter JACK sans décrochages (
Xruns
) en utilisant le type de configuration de serveur son
#JACK seul
ou
/Examples (Français)#PulseAudio+JACK
. En raison de différences selon le matériel, si un
#Realtime kernel
est utilisé ou non et si
#Optimisation de la configuration du système
est appliqué, il n'existe pas de préréglage général.
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
,
cadence
AUR
,
patchage
AUR
et
studio-controls-git
AUR
peuvent tous être utilisés comme interface graphique utilisateur pour surveiller l'état de JACK et simplifier sa configuration.
Note
Une fois que vous avez configuré JACK, essayez différentes applications audio pour tester vos résultats de configuration. Par exemple, ne passez pas des jours à essayer de résoudre les problèmes de décrochage de JACK avec
LMMS
si le problème vient de ce dernier.
Plus de lecture :
article de Linux Magazine (2006)
pour la compréhension de base sur la recherche de paramètres JACK
Vérification de la latence
Les paramètres de JACK sont les plus importants pour contrôler le
round-trip delay
(RTD). Dans le contexte de cet article, c’est le temps global qu’il faut pour qu’un signal audio soit enregistré, traité et lu. La sous-section suivante traite du contexte théorique sur les sources de latence qui s'additionnent à la RTD. Si vous êtes déjà familier avec cela, rendez-vous à
#Mesurer la latence
pour vérifier votre RTD ou sauter cette section complètement.
Les sources de latences
Envisagez une situation d'enregistrement typique d'une performance de chanteur. La voix est capturée avec un microphone alors qu'elle se propage à travers l'air à la
vitesse du son
. Une
conversion analogique vers numerique
permet d'enregistrer le signal électrique par un ordinateur pour
traitement numérique du signal
. Finalement, une
conversion numérique vers analogique
retourne le signal à lire sur les écouteurs du chanteur pour une écoute similaire à l'utilisation d'un
système de retour de scène
.
Dans cette situation d'enregistrement vocal, il y en a cinq significatives
sources de latence
la construction de la RTD et se produisant dans l'ordre suivant:
Propagation sonore à travers l'air de la bouche du chanteur
Conversion analogique-numérique
Traitement numérique du signal
Conversion numérique-analogique
Propagation sonore à travers l'air à l'oreille du chanteur
La première et la dernière sources de latence sont difficile à modifier car une distance particulière est techniquement nécessaire pour créer un son prévu lors de l'enregistrement ou de la lecture, respectivement. De plus, lorsque vous utilisez un micro plus proche pour la capture et des écouteurs pour surveiller les deux latences de propagation du son, cela se situe généralement dans la plage de quelques microsecondes, ce qui n'est pas perceptible par les humains. Ainsi, un objectif de minimisation de la RTD est de réduire les autres sources de latence.
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.
Mesurer la latence
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
.
Note
This latency value is comparable to a typical monitoring situation on stage using speakers with a distance to the performer's ear ranging between 2 m and 3 m according to the equation for the
speed of sound in air
. Performers experienced with on stage monitoring are typically used to such latencies.
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
This article or section needs expansion.
Reason:
Real-time kernel support was merged into
Linux 6.12
. How does it affect this section? (Discuss in
Talk:Professional audio (Français)
)
"
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.
Note
Currently, there are
known limitations
for using a realtime kernel with other specific applications typically related to
Virtualization
(such as
Xen
and
KVM
). If you also need those capabilities, consider installing the realtime kernel in addition to the vanilla Arch Linux kernel and creating a second
boot loader
entry for booting the appropriate kernel on demand.
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)
Optimisation de la configuration du système
Note
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
realtime
group).
Using the
threadirqs
kernel parameter
(consult
[3]
for reference) - enforced by default by the
realtime kernel
.
Using the
realtime kernel
.
Add
noatime
to
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
60
by default—to e.g.
10
will 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 with
sysctl 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 with
sysctl fs.inotify.max_user_watches=600000
or 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
archlinux met à disposition un paquet
pro-audio
qui installe toutes les applications (semi-) professionelles. Toutes les applications du paquet pro-audio sont des clients JACK. Aussi les paquets
lv2-plugins
,
ladspa-plugins
,
dssi-plugins
,
vst-plugins
et
clap-plugins
sont des sous-groupes du groupe de paquets pro-audio.
Tip
Voir
Pacman/Tips and tricks#Listing packages
pour lister les membres d'un groupe et
Pacman#Installing package groups
pour installer un groupe de paquets.
Un aperçu et de brèves informations sur certaines applications se trouvent dans
List of applications/Multimedia#Audio
. Spécialement les catégories
Digital audio workstations
,
Effets audio
et
Music trackers
, tout comme
Audio synthesis environments
et
Sound generators
fournir des exemples de logiciels audio pro pour l'enregistrement, le mixage, le "mastering" et la conception sonore. d'autre catégories incluent des logiciels
Scorewriters
,
Audio editors
,
Audio converters
, et
DJ
.
Les paquets qui ne sont pas (encore) dans les dépôts officiels peuvent être trouvés dans
proaudio
. Parcourir la
list of packages
pour trouver l'application dont vous avez besoin ou demander l'empaquetage de vos applications souhaitées via
GitHub
.
Matériel
La majorité des cartes son et des appareils audio fonctionneront sans configuration ou paquets supplémentaires, il suffit de régler JACK pour utiliser la matériel souhaité.
Ce n'est pas vrai pour tous le matériel existant, jetez un oeil à la
Category:Sound
,
/Hardware (Français)
et aussi à
Envy24control#Supported cards
pour ces cas spécifiques.
Obtenir de l'aide
Listes de diffusion
archlinux audio-pro
Discussion sur le multimédia en temps réel, y compris (semi-)pro audio et vidéo.
Utilisateur Linux Audio
La liste de diffusion liée à Linux pro-audio avec beaucoup de trafic et une énorme communauté d'abonnés d'utilisateurs et de développeurs.
IRC
#archlinux-proaudio
- Canal audio pro archlinux
#lau
- Canal audio Linux général pour les utilisateurs
#jack
- Développement et support liés au serveur son JACK
#lv2
- Développement et support liés au format de greffons LV2
#ardour
- Discussion et soutien concernant le séquenceur Ardour
#opensourcemusicians
- Grande canal de discussion générale de musicien(ne)s OSS
Voir aussi
Audio Professionelle
Guide complet pour une configuration pro-audio basée sur Arch Linux
lv2-plugins-aur-meta
AUR
— fournit de nombreux greffons LV2
awesome-linuxaudio
Une liste de logiciels et de ressources pour la production professionnelle d'événements audio/vidéo/live sur la plateforme Linux
Multimedia et Jeux / Forums archlinux
Temps réel
Le wiki de la Fondation Linux sur les correctifs PREEMPT_RT