**This is an old revision of the document!**

Low Latency Kernel

A computer's CPU does a lot, cycling constantly through series of loops and commands and probes and checks and refreshes and updates so consistently that sys admin even today talk in terms of “CPU cycles” when estimating the “cost” of a computationally intensive project. Regardless of what you do artistically on your computer, yours is no exception: the CPU is in high demand every second, and not everything demanding its attention can be tended to at the same time. For this reason, the driver of the CPU (the “kernel”) queues all tasks needing attention, delegates priorities to each one, and then executes chunks of each waiting task according to priority. This happens millions times per second.

For most everyday computing, the Linux kernel's somewhat conservative policy of what is important and what can wait another millisecond or two before getting worked on is perfect; onscreen effects get displayed smoothly, music plays seamlessly, the desktop clock keeps ticking, and no one is ever aware that user tasks are secretly being preempted for boring low-level computer tasks.

One place that this does not do well is professional audio, or more specifically, professional audio with realtime effects or realtime recording. Most other artistic tasks (even video effects) are perfectly acceptable on default settings, but pro audio requires high priority in order to playback smoothly without clicks, stutters, or breaks (called “xruns”). Technically speaking, this means that audio must gain the permission to preempt the usual priorities of running tasks as needed. Normally, this is not allowed on a Linux system, but as of kernel version 2.6.38.4 (so any 3.x or higher kernel) the ability to whitelist preemption was written into the OS.

As long as you are running a Linux kernel versioned 3 or higher, you have a preemptive kernel already and there is no need to look for a special “low latency” kernel. You are, however, required to whitelist the applications that you want to allow to preempt the kernel's better judgement.

Whitelisting

If you are doing pro (or hobbyist at the pro-level, or anything other than Audacity), then you need to manually whitelist any application dealing in low latency audio.

In casual conversations, the term “realtime” tends to mean near-instant processing of sound such that there is no noticeable delay. However, this is different from what a computer sees as realtime, so the term is abused. To keep “realtime” and “low latency” distinct from one another, Slackermedia uses “low latency” to describe what most people consider “close enough” to realtime audio as necessary, and “realtime” to only mean actual realtime processing, such as what might be needed in an active, in-production recording studio or the stock market.

To whitelist an application, use the setcap command as root. The first sensible application to whitelist is the one driving all of the pro audio tools in the first place: the JACK daemon,jackd:

su -c '/sbin/setcap cap_ipc_lock,cap_sys_nice=ep /path/to/jackd'

After jackd has been whitelisted, whitelist the other pro audio applications that you use:

  • Stand-alone synths, especially if they have inbuilt effect processors.
  • The DAW(s) that you use.
  • Loopers, beatboxes, drum machines, sequencers.

You do not need to worry about getting everything all at once; if something needs to be less nice with other processes, you'll hear it. You can whitelist it as needed, and the change will be immediate.

Realtime Kernel

Most people casually express a desire for a “realtime” kernel when they actually mean a low latency kernel, but sometimes realtime is actually necessary. For instance, multiple tracks with multiple overdub takes might require realtime response in order for the musician to keep tempo. If you find that low latency is not sufficient, you can build your own kernel with true realtime capabilities.

To build a realtime kernel, download two things;

  1. The kernel source code
  2. Realtime patches for the source code

Patching the Kernel

TL;DR
You only need to do this if you have a real need for literal realtime performance. This will make no difference to you if you are not using applications that take advantage of realtime capabilities, so don't bother doing this under the illusion that it will make your system faster for graphics editing or gaming.

The code to provide the Linux kernel with true realtime performance is maintained separately from the main kernel code itself. It is available from https://www.kernel.org/pub/linux/kernel/projects/rt, so take a look at the list of supported kernel versions and then download the latest stable version kernel that matches up with the available patches.

In other words, if the latest version number listed in the patches folder online is 4.0, then go into that folder and look at what patches are available. The patch files are labelled with the version of the kernel they support, so if there is a file, for instance, called patch-4.0.4-rt1.patch.xz then download that patch file and the 4.0.4 kernel.

Do not download the patches file (plural), but the patch file (singular). The “patches” file contains all the patches in separate documents, and will fail.

To download the kernel source code, go to http://kernel.org and download it. Alternately, you can download it using a shell based browser like wget:

$ wget http://kernel.org/pub/linux/kernel/vX.Y/linux-X.Y.ZZ.tar.bz2
$ wget https://kernel.org/pub/linux/kernel/projects/rt/X.Y/patch-X.Y.ZZ-rt1.patch.xz

You should now have two files:

  1. A single patch file for realtime.
  2. The Linux kernel source code.

Extract the kernel source and change into its directory:

$ tar xvf linux-X.Y.ZZ.tar.bz2
$ cd !$

And then apply the realtime patch:

$ xzcat ../patch-X.Y.ZZ-rt1.tar.xz | patch -p1

You will see a few screen-fulls of text and eventually get a bash prompt back.

Now you can compile the new kernel.

Compiling the Linux Kernel

Configuring a kernel from scratch is a big job. It's arguably worth doing, but it requires solid knowledge about the hardware in your computer, down to the individual components. You only have to do the configuration once per computer, since you can inherit old configs and just add to them in the case of a new kernel.

Better yet, you can take advantage of the hard work that Slackware's maintainer, Patrick Volkerding, has done and inherit his configuration.

To do that, copy the Slackware kernel config file into the kernel sources folder. Find the kernel config files in /media/{cdrom}/testing/source/linux-X.X.XX.X-configs or on any Slackware mirror; for example, ftp://ftp.slackware.com/pub/slackware/slackware-XX/testing/source/linux-X.X.XX.X-configs/.

Presuming an SMP-capable CPU (you would know if your CPU is not SMP-capable), you will notice that there are two configuration files; the generic kernel configuration and the huge kernel configuration. By default, you are using the huge config, but this doesn't mean you have to keep using it. If you feel that your hardware is well-supported by the Linux kernel, then you may wish to try operating on a more lightweight kernel. You can always re-compile to a huge kernel if it turns out to be necessary.

# cp /media/cdrom/testing/source/ linux-X.X.XX.X-configs/config-generic-smp-X.X.XX.X-smp /path/to/linux-X.X.XX.X/.config