Linux & Audio Latency

Audio latency is a critical component of digital audio systems. `Latency' is a highly significant element in applications involving real-time audio synthesis and/or processing ("FX"). For synthesis, latency determines the shortest time between an external event arriving (e.g. a MIDI Note On) and a change in the audio output that reflects that event . For FX, latency determines the shortest possible time between the arrival of an external audio signal and its appearance as a (processed) output signal.

Current typical professional digital audio systems using custom hardware (ProTools, Event's Layla, Ensoniq Paris etc.) have latencies in the range of 3-7ms. Such figures are exceedingly difficult to get from Microsoft's operating systems (Windows, etc.)or those for the Macintosh. Currently, some programmers using Microsoft's DirectX audio subsystem have gotten as low as 5ms, but only with considerable effort to work around the design of DirectX.

However, even if such low numbers can be achieved some of the time, they are impossible to keep up if the computer is busy doing other things. Since `other things' may include storing an audio signal on a disk drive, or putting a display of the signal on the screen, this can be a big problem. It has typically meant that pro-audio companies have reverted to custom, external hardware (and in many cases, entire custom operating systems) to ensure reliable, low latency processing and synthesis.

This is all about to change forever with Linux

Linux is a multipurpose operating system capable of running on a wide range of computer hardware. It can provide operating system support for a web server, a high performance numerical workstation, a high-end database server, a sophisticated graphics design tool, and many others.

With the latest developments for Linux, off-the-shelf computing hardware can now do reliable low latency audio synthesis and FX processing with performance exceeding that of any other general purpose operating system on the market, and better than most dedicated hardware.

Audio Latency Test Results

AKA, can your company do better than this even with custom hardware?

The charts below show the outstanding results.

Test Summary

A current, available version of Linux running on a PII-400 can support an computationally demanding application requiring 2.1ms of audio latency. There will be no audio dropouts even in the presence of other significant system activity.

Linux is therefore an obvious choice to support such applications as:

real-time software synths
real-time FX processors
MIDI sequencers with high precision timing.
Harddisk recorders

Linux now provides the necessary capabilities to keep up with the performance of pure hardware based solutions. For example, it's now possible to use your Linux box as an FX processor with rock solid 5ms latency, (no sound dropouts) even when the disk is doing heavy I/O.

Linux would now even allow an entire Cubase VST-like application to run in a 5ms-latency enviroment. This would mean that VST plugins could process the audio-input of the soundcard in realtime (with 5ms latency), while playing back your 50 audio tracks from the disk, all without dropouts. All parameter changes on EQs/Filters/Plugins/Volume etc. would be heard in in realtime, just as on custom-hardware based solutions.

This assumes that your processor is fast enough to do all the required processing on 5ms of sound in about 4 to 4.5ms. Nowadays, with 400MHz processors common, this is pretty likely. But don't worry, if it isn't fast enough to do all that you want today, thanks to Intel and Motorola's R&D, it will be tomorrow!

Test Description

This test was designed to determine the performance of Linux and in particular its audio subsystem. We used a test program that simulates an application such a real-time software synthesizer and/or FX processor.

The test sets up a soundcard to use a buffer that contains 2.1ms of sound. We then playback some sound, at the same as using of 80% of the processor's time (as if our program was a real-time software synthesizer or FX processor). Simultaneously, we start other programs that display rapidly changing graphics, read, write and copy to/from disk, and interact intensively with the internals of the operating system. Using a high precision, nano-second resolution timer, we measure whether there is ever an audio dropout (often audible as a "pop" or "click").

Test Results

Each chart contains the following elements:

the red reference line marks the 2.1ms point, a critical deadling: if this is ever crossed, an audio drop-out will occur, probably with audible effects.
the white line is the actual scheduling latency, the ideal would be the time it takes to play 1 audio fragment. (fragment latency)
the green line is the time the CPU takes to execute an empty loop (which is calibrated at 80% of the fragment time)

this is used to simulate heavy CPU computations during the audio play, a typical example could be a synthesizer which computes the waveform to play in realtime.
since the thread runs with SCHED_FIFO priority, if this time goes up, then the cause could be the DMA / PCI / ISA contention on the system bus, or busy kernel I/O routines
- the yellow reference line is the len of one audio fragment (ideally the white line should stay close to yellow line)
- the white between +/-1ms is the % of time the total latency stays in the range between +/-1ms of the optimal latency.
- the white between +/-2ms is the % of time the total latency stays in the range between +/-2ms of the optimal latency.
- the green between +/-0.2ms is the % of time the CPU loop latency stays in the range between +/-0.2ms of the nominal CPU loop latency.
- the green between +/-0.1ms is the % of time the CPU loop latency stays in the range between +/-0.1ms of the nominal CPU loop latency.

X11 stress