THIS PAGE IS UNDER CONSTRUCTION. FEEDBACK DURING CONSTRUCTION IS WELCOME.

This page is a practical Linux audio information guide. It covers things most users can actually do/check to improve their Linux audio computers.

• System configuration
  • Hardware
  • Groups and permissions
  • Real-time (RT) kernel
  • JACK
• Basic software setup
  • Desktop environment
  • JACK control
  • Suggestions for basic recording and mixing
  • Suggestions for general audio editing
  • Suggestions for MIDI sequencing

System configuration

These are the basic components of a well-configured, professional Linux audio distribution.

• Hardware
• Groups and permissions
• Real-time (RT) kernel
• ALSA
• JACK

Hardware

What computer components your computer should have depends on what you intend to do.

CPU

• If you are going to focus on MIDI control/live MIDI, a dual-core processor should work.
• If you are simply going to record raw audio, even multi-track, but not use plugins, a quad-core processor should work.
• If you are going to perform plugin-intensive mixing, quad-core processor could still work, but at this point more is better.

RAM

• If you are only going to record and do mixing/mastering/plugins elsewhere, 8 GB RAM should work.
• If you are going to get into heavy plugin use, you should probably have at least 16 GB RAM.
• For all cases, faster RAM is always better, but no less than DDR3.

Hard drives

I personally recommend having a system with a solid-state drive (SSD) that loads and runs your operating system, and a 7200 RPM hard disk drive for storage. If you don’t have an SSD, you definitely need to have a 7200 RPM disk drive, or xruns under intensive use might be unavoidable.

Groups and permissions

Your user needs to be in an audio group with appropriate privileges. A modern Linux audio distro should have a file in /etc/security/limits.d/ dealing with permissions for the audio group, and that file should look like:

@audio - rtprio 95
@audio - memlock unlimited

Note that /etc/security/limits.conf should no longer be used. If this file exists and it has the correct audio group settings, you can simply move it into /etc/security/limits.d/ and rename it.

To account for any hardware timers, such as a real-time clock (/dev/rtc) or high-precision event timer (/dev/hpet), there should also be a file in /etc/udev/rules.d/ dealing with these devices, and it should contain:

KERNEL=="rtc0", GROUP="audio"
KERNEL=="hpet", GROUP="audio"

It is safe to have this file even if your hardware contains neither device, so you can include/create it if you are not sure.

The exact names of these files does not matter. Only the file location matters – they must be in the respective directories mentioned above.

Real-time (RT) Kernel

If you are simply going to record, and you know you will never, ever need to handle any type of live situation, you do not need a real-time kernel. For this, a low-latency desktop (“normal preemption”) will suffice.

However, most people who go looking for a professional Linux audio distro can never say for sure they will never, ever have anything to do with a live situation. Skip the hassle of uncertainty and set up a real-time kernel from the beginning for the following reasons:

• For a given set of settings – for example, a buffer size of 256 samples, a 48 kHz sample rate and 3 periods – a real-time kernel is more stable for audio and MIDI. I have witnessed this repeatedly on my own systems.
• Live MIDI jams. A 32 ms latency on a low-latency desktop that works for recording will leave you pressing keys and literally hearing the sound a split second later.
• If you use a software synth connected to a MIDI controller/keyboard, you will certainly want your latency to be under 10 ms.

A real-time kernel with full-preemption is therefore recommended for any professional Linux audio distro.

What is latency, anyway?

Kernel configuration options

All of the currently available Linux audio distros provide pre-compiled kernels. You should confirm that the kernel has the PREEMPT_FULL option enabled and the timer is set to 1000 Hz.

If you want to check your kernel in more detail – and I think this is a good idea if you are serious about making sure your system works as well as possible for all types of professional audio and MIDI use – and for those compiling their own kernels, whether with genkernel or a more manual approach, you should check for the following settings in menuconfig. These are also the settings that ideally should already be set in a Linux audio distro’s kernel.

[*] means an option should be enabled in-kernel.

<M> means an option should be enabled as a module.

[ ] or < > means an option should be disabled. If it is not mentioned at all, leave the default option as-is unless you know what you are doing.

• Processor type and features
  • Preemption Model
    • [*] Fully Preemptible Kernel (RT)
• Power management and ACPI options
  • [ ] Suspend to RAM and standby
  • [ ] Hiberation (aka ‘suspend to disk’)
  • [ ] Device power management core functionality
  • [*] ACPI (Advanced Configuration and Power Interface) Support
  • CPU Frequency scaling
    • Default CPUFreq governor
      • [*] performance
• Device Drivers
  • <M> Sound card support
    • <M> Advanced Linux Sound Architecture
      • <M> Sequencer support
      • <M> Sequencer dummy client
      • <M> OSS Mixer API
      • <M> OSS PCM (digital audio) API
      • [*] OSS PCM (digital audio) API – Include plugin system
      • [*] PCM timer interface
      • [*] OSS Sequencer API
      • <M> HR-timer backend support
      • [*] Use HR-timer as default sequencer timer
      • [ ] Dynamic device file minor numbers
      • [*] Generic sound devices —>
        • < > PC-Speaker support (READ HELP!)
        • < > Dummy (/dev/null) soundcard
        • <M> Generic loopback driver (PCM)
        • <M> Virtual MIDI soundcard
        • [ ] AC97 Power-Saving Mode
      • [*] PCI sound devices —>
      • HD-Audio —>
      • [*] USB sound devices —>
        • <M> USB Audio/MIDI driver
      • [*] FireWire sound devices —>
      • [*] PCMCIA sound devices —>
      • < > ALSA for SoC audio support
  • [*] Real Time Clock —>
  • < > Open Sound System (DEPRECATED)

Notes:

• Users have reported mixed results with running audio processes and standby/hibernate. I don’t think it’s worth using, and the kernel should not even have this option. That said, ACPI should be left enabled because you’ll want to be able to view your laptop’s battery life and other things.
• Dynamic device file minor numbers: This is related to having more than eight sound cards. Not sure what anyone would be doing with so much as eight sound cards on one system, let alone more than eight, so disable this option.
• PC-Speaker support and Dummy: These are not useful for a professional audio production system.
• AC97 Power-Saving Mode: You do not want this even if you have this sound card. You generally do not want power saving anything on a real-time audio system.
• PCI sound devices, USB sound devices and FireWire sound devices: These are nothing more than lists of drivers for specific sound cards. A pre-compiled kernel on a professional Linux audio system should include them all as modules to cover all bases. If you are compiling your own kernel, select only the sound card(s) you have or expect to use.
• HD-Audio: Enable only if you have an internal Intel HD audio chip and you plan to use it.
• ALSA for SoC audio support: Not relevant to desktop audio systems.
• Real Time Clock: Leave the defaults as-is unless you happen to know the particulars about any real-time clock your system might have.
• The latest kernels have an ALSA Firewire driver stack. It is still experimental, so the standard Firewire stack should continue to be used for now.
• Please do not compile ALSA modules into the kernel. While they should still work, there may be times when you, the kernel, or some other process may need to load/unload a specific module at a specific time for a specific reason. The biggest example of this need is simple troubleshooting. Why isn’t x working? You can use lsmod to look for the module, or you can unload a module that might be conflicting with another.
• Genkernel is recommended for making changes to your kernel (make sure /boot is mounted!)  via the root command genkernel --menuconfig all

In addition to the above kernel settings, you want to completely eliminate swapping. If swapping occurs while recording, you WILL get an xrun and your recording will be ruined.

You also want to use whatever hardware timer at a higher frequency than the default. Rosegarden is one program that relies on these values, and you should use the values Rosegarden recommends.

You should have a file called /etc/sysctl.conf and it should contain

vm.swappiness = 10
dev.rtc.max-user-freq=3072
dev.hpet.max-user-freq=3072

Newer kernels may not use this file to set the rtc and hpet values, so you should check for the following two files and change the values within them if they exist to the values mentioned above:

• /sys/class/rtc/rtc0/max_user_freq
• /proc/sys/dev/hpet/max-user-freq

Do not create these files if they don’t exist.

ALSA

ALSA stands for Advanced Linux Sound Architecture and should already be present in your kernel as described earlier. In addition, alsa-tools and alsa-plugins may be useful to you. Both of these can be found at https://alsa-project.org or in your distro’s repositories.

I really do not recommend using Pulseaudio, and consider it very much a “use at your (extreme) risk” item for a stable, functional LInux professional audio system.

JACK

JACK stands for Jack Audio Connection Kit and is in my mind the de-facto standard for controlling audio and MIDI on a professional Linux audio system. A properly tuned JACK setup along with a correctly-configured real-time kernel should provide you with a stable audio/MIDI platform with no xruns during normal operation.

You cannot simply set JACK parameters to what you ideally want and expect it to just work, though. You need to find the most stable settings for your particular system. For example, you can set everything so that you have a 1.7 ms latency, but find that you have occasional xruns. Don’t get hung up on having a latency that is the absolute lowest possible. You want the lowest possible latency for your specific system that produces zero xruns.

• Start with an appropriate sample rate. Some hardware allows for up to 192 kHz. This is not a magic bullet, or even useful at all according to some very reputable sources. A higher sampling rate will lower your latency, but might not work very well with certain plungins. A couple of examples include:
  • A drum plugin using a variety of samples taken at 41 or 48 kHz might instantly push your DSP load to 100% at a 192 kHz JACK setting.
  • You might record somewhere on one machine and process the audio further on another, so if you have a laptop you record on and a desktop where your mixing board is 48 kHz, you should set your laptop to 48 kHz even if you have a Focusrite that does 192.
• 48 kHz is a perfectly acceptable sampling rate, and you should start with that, unless your hardware runs at 44.1, which is also perfectly fine.
• Your periods/buffer should be 2 or 3. Try 3 first, then switch to 2 if you’re still having xruns later.
• Set your buffer size to the highest possible setting: 8192. Run JACK and perform some audio tasks equal to what you would normally do. No xruns? Set it to the next highest setting. Repeat until you start getting xruns. Your optimal setting is the one you used before you started getting xruns.
• It is likely at this point that you have a latency of under 10 ms. You should now be good to go.

Basic software setup

Desktop environment

There are some things you should avoid in a real-time, professional Linux audio system:

• Monolothic desktop environments such as Gnome and KDE. These are resource hogs. All the bells and whistles they provide take resources away from real-time audio processing, even with real-time and full preemption. Do not use a monolithic desktop, even on a mega-powerful machine. There are users who do just fine with it. I still don’t recommend it because I really think a good Linux audio system for professional use should focus on leaving free as many resources as possible for audio processing. If you want something “easy to use,” Xfce4 and LXDE are almost functionally indistinguishable from Gnome or KDE and have much smaller  resource footprints.
• File indexing. This is a cron job running in the background and could cause xruns. If you are avoiding Gnome and KDE, though, you probably do not have file indexing by default.
• Screensaver. It’s an unnecessary daemon that blanks your screen inconveniently when you’re recording.
• Power management. You want your system on, and you want it ready to go with all resources available. If you are concerned with power consumption, simply turn off your system when not in use. That said, you can still use the Xfce4 Power Manager to ensure that your video monitor stays on and does not blank inconveniently. I have not noticed any adverse affects to using Power Manager for this purpose. If you are not using Xfce4, the following commands can be put in an appropriate user-login file to keep your video monitor from blanking:
  • xset s off
  • xset s noblank
  • xset -dpms
• CPU frequency scaling governors. Same reason as power management.

These are things you should be using:

• A lightweight desktop environment such as Xfce4 or LXDE, or even just a window manager such as Fluxbox.
• A terminal emulator with a small resource footprint. rxvt-unicode is an excellent terminal for this purpose, and if you don’t like manually editing config files to make it look less bland, it has a configuration editor called urxvtconfig.

Things that may or may not matter:

• WiFi. Some systems with WiFi produce xruns, and others do not. You will simply have to try it and see. Sometimes WiFi will cause xruns for certain actions but not for other actions. For example, on one laptop, WiFi didn’t affect my normal audio setup, but when I attempted to use Netjack over WiFi, it spat out xruns by the boat-load.
• Compositing. I use compositing with Xfce4 because I like certain visual cues such as inactive windows being more transparent. It does not seem to affect my audio setup at all, but you will have to try it and see what happens on your own system.

JACK control

There are four well-known ways to control jack.

• From the command line.
• Using QjackCtl.
• Using Cadence.
• Allowing your programs to start and stop JACK.

This document was last updated in May of 2018.