For audio production and processing, your system needs to be optimized for low latency operation using the Jack Audio Connection Kit (JACK) audio server with Advanced Linux Sound Architecture (ALSA) compatible audio interface hardware. Today class-compliant USB audio interfaces are supported out of the box as well as IEEE 1394 aka Firewire devices since the introduction of Juju. Audio applications use JACK for low-latency operation and signal routing. Extensive documentation may help to understand some principles and general guidelines when trying to setup a professional audio environment.
The Linux kernel is compiled with
CONFIG_PREEMPT=y by default in most distributions and worst case latency is normally up to 10 ms. So for starting you might want to stay with the stock kernel, but depending on hardware and requirements you may need a real-time (RT) kernel. Use your package manager to install
linux-rt or similar. In Arch Linux there are no official builds, so you would need to build the RT kernel by yourself, if you don't trust the Arch User Repositories (AUR) by Arch Linux developer dvzrv.
After installation reboot into that kernel and optionally check its configuration on terminal with:
gzip -cd /proc/config.gz | grep PREEMPT
Some distributions store that file in
/boot directory and if
CONFIG_IKCONFIG, but not
CONFIG_IKCONFIG_PROC is present, you can extract it out of the kernel image with extract-ikconfig.
As low-latency is important for an audio setup there are some settings to be tweaked for using full system resources and improving performance for access on hardware. Most of those optimizations are based on the ArchWiki as well as recommendations from linuxmusicians.com and can be checked by a perl script. Get and execute that script like this:
git clone https://github.com/raboof/realtimeconfigquickscan cd realtimeconfigquickscan perl ./realTimeConfigQuickScan.pl
Then follow instructions for all check results classified not good. Some of the commands for optimization need to be run with sudo or as superuser. So be careful when executing them!
echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
%wheel ALL= NOPASSWD: /usr/bin/cpupower frequency-set -g performance
High swappiness values causes the system to swap running applications to hard disk even if there's still memory resources available. Lower swappiness by adding
vm.swappiness=10 to /etc/sysctl.conf file.
The maximum number of files your system can monitor with inotify is specified in /etc/sysctl.conf file, too. Increase the max_user_watches parameter by appending
fs.inotify.max_user_watches = 600000 to it.
Both settings are provided by an AUR package called
realtime-generic-setup in Arch Linux. Activate new configuration by reloading sysctl with
For access to the high precision event timer and real-time clock is necessary. Normally those are owned by the audio group, so you must be part of that group:
gpasswd -a <username> audio
RT priorities and memlock setting needs to be specified in /etc/security/limits.conf file to allow applications to use most of the system resources:
@audio - rtprio 90 @audio - memlock unlimited
In Arch Linux the package realtime-privileges provides that configuration and you need to be part of the
realtime group instead.
Note: Changes concerning group membership are applied on next login.
Another crucial task, especially for external audio interfaces using USB, Firewire etc. connection, is IRQ handling. Although this is done automatically, I found that manually prioritizing IRQs reduces latency. The process is to identify IRQs with
rtapp and set priorities with
rtirq as described for Audio Linux project.
Connect your audio interface and identify current IRQ handling with
rtstatus on terminal. If the output is similar to this:
RTPRIO COMMAND 50 irq/16-ehci_hcd 50 irq/30-xhci_hcd ...
rtcards to examine IRQ and interface of DAC to specify it for
RTIRQ_NAME_LIST in /etc/rtirq.conf file. I'm using an USB 2.0 audio interface requiring
ehci_hcd (default is
xhci_hcd) value, for example. There's no further editing needed as default
RTIRQ_PRIO_HIGH=90 is fine. Changes are applied when rtirq service is restarted:
systemctl restart rtirq
Enable the service with
systemctl enable rtirq to change IRQs automatically at boot.
In the center of audio applications the JACK audio server guarentees low-latency operation, signal routing and connection management. There are two versions available. To maintain multimedia capabilities (e.g. audio in web browsers) provided by PulseAudio (PA) and use multi-core CPUs efficiently,
pulseaudio-jack module needs to be installed along
jack2 with SMP and D-Bus support.
The hardest part is to evaluate best JACK parameters depending on your hardware. To ease this procedure and control JACK graphically
qjackctl can be used. Besides general settings for starting
jackdbus instead of
jackd service, main parameters regarding to latency (frames, periods, sample rate) are described by this function:
L = n * p / f
L: Latency in miliseconds (ms), n: Frames or buffer (multiples of 2, starting at 16), p: Periods, f: Sample rate in Hertz (Hz).
Capabilities of the audio interface define working combinations. You have to trial and error to find a setup. Sure, it's a trade-off between xrun prevention and latency, but recent audio interfaces can be used at high sample rates (up to 192 kHz) to deal with that requirement. Start your evaluation by choosing a period of 2 or 3 (for external audio interfaces) and try frames values ranging from 16 to 256. Some combinations have been documented in the Linux Audio Wiki. If you do mixing only and don't plan to use live processing and recording with software monitoring in your Digital Audio Workstation (DAW), the frames value can be much higher as there might be more processing power needed over real-time performance capabilties.
For instance, I'm using n=3, p=128 and f=48000 resulting in a latency of L=8 ms for recording with a USB audio interface and software monitoring. Mixing only setup uses a higher frames value of p=1024 with my built-in audio interface.
There are many applications for different tasks and workflows. In the audio context it's important that they are JACKyfied, which means supporting JACK for audio in-/output. Be inspired by the following list of applications I'm using:
|Application name||Description and highlight features|
|ardour||Cross-platform DAW: unlimited tracks and buses, automation, MIDI support|
|Audacity||Extensible audio editor with encoding and plugin support, cross-platform|
|cdrdao||Audio and data recording of CD-Rs in Disc-At-Once (DAO) mode|
|FluidSynth||Software synthesizer using SoundFont format for voicings|
|ddptools||Disc Description Protocol (DDP) mastering for CD Red Book format|
|Hydrogen||Drum machine featuring custom drumkits and separated JACK outputs for each instrument|
|Jamulus||A tool for online jam sessions in real-time|
|ladspa-plugins||Package group for a collection of LADSPA plugins|
|lv2-plugins||Package group for a collection of LV2 plugins|
|Patchage||JACK connection management (software patch panel) for audio and MIDI|
|qsynth||Graphical control of FluidSynth written in Qt|
|TuxGuitar||Tabulature editor with GuitarPro and PowerTab format support|