Miscellaneous Settings

The Block Layer configuration section includes three options for choosing your system's I/O scheduler. The Anticipatory scheduler is the normal system default, the Deadline scheduler is recommended for systems running large databases, and the CFQ scheduler is advised for load averaging on normal desktop systems. If you choose to build all three schedulers, you must declare one to be the system default. The CFQ option is the scheduler of choice for low-latency systems.

The Kernel Hacking section includes support for the Magic SysRq key (CONFIG_MAGIC_SYSRQ), a handy amenity for anyone using a preemptive kernel. This option enables the use of the SysRq key in combination with other keys to recover a frozen machine or reboot a machine without corrupting the filesystem. The Magic SysRq Key page on Wikipedia has a full list of magic key combinations.

Latency and the Real-Time Kernel

On the Wikipedia disambiguation page for "latency," numerous references share the common identifying factor of a time delay between an event's initiation and its realization. Under normal circumstances, latency might not be an issue, but as playback and production demands increase, so does the possibility for disruptive latency. Much of the information here is directed toward lowering latency, but a normal Linux kernel cannot reach the range of latency considered to be acceptable in professional applications. Fortunately, thanks primarily to the work of kernel developer Ingo Molnar, a set of patches are available that can dramatically reduce latency in the kernel – down to and beyond professional limits [2]. Most of the media-optimized Linux distributions include a real-time kernel, and most of those kernels are patched with Molnar's work.

Molnar has identified six traditional sources of latency in the Linux kernel:

• Calls to the disk buffer cache
• Memory page management
• Calls to the /proc file system
• VGA and console management
• Forking and exiting large processes
• The keyboard driver

These factors can delay the return of control to the scheduler for several milliseconds, and with enough delay, audio dropouts and video frame loss will occur. Molnar's patches tune these factors until kernel latency reduces to less than 5msec, a very dramatic reduction from the latency of an unpatched kernel and within professional limits. However, low latency also depends on audio hardware capabilities, and in some instances, latency might not be so reducible.

The term "real-time," with regard to the kernel, has two rather different meanings. The real-time kernel I've been configuring here is "soft"; that is, it can promise to deliver the goods within a certain time, but it can't make a guarantee. By contrast, a hard real-time system guarantees the delivery within a specified time frame. In neither of these usages do you find any necessary reference to low latency, although typically, a real-time system operates within tight time constraints, even down to microsecond levels. The essential difference between hard and soft real-time systems is criticality: If Ardour suffers an audio buffer overrun, I might get upset over the resulting glitch in my recording, but if the real-time control system software for a nuclear power plant misses a few beats, then we're all in serious trouble.

The Real-Time Kernel in Real Life

Table 1 compares the three machines I use here at Studio Dave. All systems are configured for PREEMPT and RT, and all machines have nVidia graphics chipsets. Big Black is my main production box, which I use for recording with Ardour, composing with Csound5, producing CD/DVDs, and managing all my teaching-related activities. The3800 is used mostly for composing with MIDI, watching movies and DVDs, and running Windows music and sound software under Wine. Until recently, it has also been my box of choice for surfing the video web, but that could change with the availability of 64-bit Flash and the 64-bit Java plugin. Maximus is my cutting-edge machine; it's used mostly for testing software that requires the latest Qt and Gtk, such as Qtractor and Ardour3.

Big Black and The3800 run on distributions optimized specifically for enhanced multimedia performance. Both machines include M-Audio Delta 66 audio interfaces, and both report 5.8msec latency in the JACK audio server. Maximus runs on a Molnar-patched real-time kernel; otherwise, its system is unmodified Ubuntu. It is also the least stable of the three systems, and I don't plan to use it for audio or video production purposes. Maximus is a notebook with an Intel HDA audio chipset, but I've added an Edirol UA25 USB interface to its audio capabilities. Alas, I have yet to bring latency below 11msec without xruns (ALSA-speak for buffer excess or insufficiencies), but I still have some module options to explore.

All of my machines are set up to run Jean-Pierre Lemoine's AVSynthesis, a program that manipulates and blends image and sound into fantastic animations. Because it needs abundant resources, it's an excellent application to use to test multimedia capabilities. Its sound production relies on Csound5 compiled for high-definition audio, its video capabilities depend on OpenGL and hardware-accelerated 3D graphics, and it can be operated in real time.

I also looked for information regarding kernels used by other optimized distributions. Fedora-based Planet CCRMA [3] offers stable real-time kernels from the 2.6.24 series and testing kernels from the 2.6.26 releases. Debian-derived Musix [4] uses a stable 2.6.21 real-time kernel in its 1.0 R2 release. Gentoo-based Bardix 0.1 [5] employs a real-time 2.6.25 kernel. From this information, you can see that distributions optimized for multimedia production and performance clearly prefer the 2.6 kernel series.