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.

Other real-time configuration options to consider when building the kernel by yourself is setting timer frequency to 1000 Hz and disabling APM:

• CONFIG_HZ_1000=y
• CONFIG_APM=n

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!

Changing CPU frequency can cause xruns and lead to audible artefacts like dropouts or distortions. So it's better to set your CPU scaling governor to performance mode. You can do this on terminal:

echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

I'm using cpupower along with following sudo configuration to allow it without root password prompt:

%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 sysctl -f.

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.

For Arch Linux the packages rtirq and rtapp are provided for installation with package manager. Append threadirqs to kernel parameters in boot configuration and reboot to apply changes.

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

run 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:

While tuxguitar package is not provided in official repositories, you can get it from coderkun-aur or start binaries directly after download of compressed archives.

Regarding to ardour and tempo/measure changes there's a Python script to apply tempo map information intended for klick metronome software to an ardour session automatically: klick2ardour.

There are more details for special hardware devices in the ArchWiki hardware section and you may want to read about general tips and tricks, too.

Category: FLOSS media studio