LinuxDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


Achieving Low-Latency Response Times Under Linux
Pages: 1, 2, 3, 4

Low-latency in the real world: performance & programming examples

The POSIX specification provides a "soft" real-time API with the SCHED_FIFO macro. Programmers can add real-time scheduling to their applications by adding a very small piece of code to raise the application's performance priority. Benno Senoner has suggested this fragment:



#include <sched.h>  
int set_real-time_priority(void)
{
struct sched_param schp;
    /*
     * set the process to real-time privs
     */
    memset(&schp, 0, sizeof(schp));
    schp.sched_priority = sched_get_priority_max(SCHED_FIFO);

    if (sched_setscheduler(0, SCHED_FIFO, &schp) != 0) {
            perror("sched_setscheduler");
            return -1;
    }

     return 0;

}

Benno also advises programmers that "... A low latency kernel alone is not enough to get dropout-free real-time audio I/O: the application must be written in such a way that the audio thread never blocks (except when doing audio I/O), and all communication with the outside world must be done by using lock-free datastructures like shared-mem and lock-free FIFOs."

Ecasound in interactive mode.

Figure 1. Ecasound in interactive mode.

For a practical demonstration of an application running with real-time scheduling on a low-latency Linux kernel, I decided to employ Kai Vehmanen's ecasound [Figure 1] in its capacity as a hard-disk recorder. The project included recording from four-track and stereo tapes to the EIDE drive on my computer. Sessions in ecasound can be prioritized to real-time scheduling by setting the -r flag, calling this code from eca-main.cpp.

Here is the full command sequence I used to launch ecasound:

ecasound -c -b:4096 -r -i:alsa,0,0,0 -o:my_foo.wav

The -c flag starts ecasound in interactive mode, the -b setting declares the audio buffer size, the -r flag raises priority to real-time scheduling, the -i settings declare the input device (ALSA here, with card, device, and subdevice numbers), and the -o flag names the output file (by default a 16-bit stereo recording at 44.1 kHz).

My project has proceeded smoothly. Ecasound performs flawlessly in console mode and in X, recording multitrack input to stereo WAV files that I burn to CDs using the excellent gcombust (a GTK-based front-end for Joerg Schilling's cdrecord and Eric Youngdale's mkisofs, both standard items on most mainstream Linux distributions).

Figure 2: SoundTracker (click for full-size view).

In the source code to Michael Krause's SoundTracker [Figure 2], you can find a switch to compile the tracker so that it runs as a real-time process. (For those who don't know: A tracker is basically a sequencer for sound samples, typically handling dozens of samples within a composition. A tracker is thus a prime candidate for enjoying the benefits of lowered latency times.) In SoundTracker's audio handling thread (audio.c), once again we see this priority scheduling code.

Michael's comment about his kernel crash was made regarding an unpatched 2.2 kernel. I ran SoundTracker 0.6.0 with no problem under the patched 2.4.0-test9 kernel, so I decided to do a little stress-testing of my own. I played a series of mods (music modules created by trackers) in SoundTracker while browsing the Web and catching up on my e-mail (in Netscape, a well-known resource hog). I also opened a few extra terminal windows in the five workspaces I had open in Blackbox (my window manager of choice). Even switching between workspaces caused no skipping or dropouts while the modules played.

MusE

Figure 3: MusE (click for full-size view).

Werner Schweer's MusE [Figure 3] is a fine audio/MIDI sequencer in development. It already has an excellent features set including syncronization with external MIDI devices and real-time editing. It is also one of the few Linux sound applications specifically requesting a kernel built with low-latency and real-time clock support. I built and ran version 0.2.7 using the ALSA 0.5.9d drivers and subjected it to one of my denser MIDI files. Performance was very good when using the external MIDI port of my SBLive, less so when accessing the SBLive's onboard synth, but I believe the problem to be due more to the card than to MusE. Many of my own MIDI compositions utilize particularly dense tempo tracks, often with tempo changes occurring continuously at the 16th-note triplet level throughout an entire piece. I downloaded other MIDI files from various sites on the Web and had no performance problems when playing them through MusE.

XMMS with DeFX and QuiXound plugins

Figure 4: XMMS with DeFX and QuiXound plugins (click for full-size view).

XMMS [Figure 4] is a wonderful media player for X, with support for a variety of audio and video formats, thanks largely to its plug-in structure. Plug-ins are also available for a wide range of audio processors, including echo generators, sound spatializers, and multi-effects panels. So as a final test I set XMMS to run with real-time priority under the 2.4.0-test9 low-latency kernel. I then activated the Effects Output plug-ins to test various effects in real-time. The DeFX plug-in (seen in Figure 4) does not pretend to replace a professional audio DSP box, but it was great fun to adjust its parameters in real time. Response was immediate and smooth, even when switching between effects. The QuiXound 3D Surround plug-in (also seen in Figure 4) was equally responsive, creating some striking localization and spatialization effects in real time.

Andrew Morton suggested that I repeat these tests using an unpatched 2.4.0-test9 kernel with untuned drives. I did, and the results were quite interesting. SoundTracker ran well even without the patch and tuning, probably because it runs setuid and I compiled it with SCHED_FIFO support. XMMS also worked well without real-time scheduling, but with somewhat sluggish response during the real-time effects parameter adjustments. MusE was audibly affected when run without real-time priority: Timing dragged during especially heavy MIDI data streams, and playback skipped when I switched workspaces in the X. Ecasound was the most severely affected, even with the real-time priority flag set, probably due to the nature of the test (CD-quality stereo recording). The program reported multiple under-runs through the ALSA PCM device (/dev/pcmC0D0), and the resulting WAV file was ruined by sixteen dropouts in a three-minute recording. As you have already learned, none of these problems occurred when running the same tests under the kernel patched for low latency on a machine with tuned drives.

Status of the low-latency patches and Linux kernel development

On-line Resources

Benno Senoner's Web sites are at gardena.net and linuxdj.com

Andrew Morton's patches

Ingo Molnar's patches

Paul Winkler's low-latency mini-HOWTO

Cakewalk's very interesting NAMM presentation

D. Glen Cardenas's in-depth research on SCSI vs. IDE disks

An excellent collection of technical and explanatory material on low latency can be found at John Littler's M-station

Information about the Linux Audio Development group can be found on the LAD Home Page

Most of the software mentioned in this article can be found linked on the Linux Sound & Music Applications Pages

In June 2000, a semi-official "expected features" list was posted to the Linux kernel mailing list in preparation for the 2.5/2.6 kernel tracks. The Linux audio community was dismayed to see that the status of the ALSA drivers had dropped to "wish" instead of "needed," while Ingo's low-latency patches were not even mentioned.

A short time later, a message was drafted by the members of the Linux Audio Development group and sent to Linus Torvalds and the kernel development group. The message explained the desirability of low latency in audio and multimedia applications and the importance of Ingo's patches.

The resulting "tempest in a teapot" eventually settled on a few critical points: First, Linus rejected Ingo's patches because of their inelegance (an opinion shared by Ingo himself) and their effect on kernel maintenance, not because he necessarily believed that optimizing Linux for multimedia is a bad idea. Next, recommending RTLinux (a "hard real-time" kernel especially suited for industrial and embedded applications) was itself an inelegant solution to the problems facing Linux audio and MIDI developers. Finally, work began on cleaning up Ingo's patches, and the results from Andrew Morton bode well for eventual inclusion into the kernel.

Of course, nothing stops you from applying one of the available patches yourself, just as you are free to replace the kernel sound modules with the ALSA drivers (which are now likely to be included in the 2.5 kernel development cycle). I urge you, if you're interested in this, to try installing one of the supported kernels and testing the appropriate low-latency patch. And I only ask that when you've been duly impressed, maybe you could drop a little hint to Linus and the kernel development team, just to let them know how much better all your audio and video applications ran with the low-latency patch to the kernel of their otherwise most excellent operating system.

Acknowledgments

The author would like to thank Benno Senoner and Andrew Morton for their extensive assistance in the preparation of this article. They also deserve, along with Ingo Molnar and Roger Larsson, great thanks for their work to make Linux an exceptionally capable multimedia platform.

Dave Phillips maintains the Linux Music & Sound Applications Web site and has been a performing musician for more than 30 years.


Also this week:

LAMP Lighter: The Apache Toolbox

Basic Installation of PHP on a Unix System

Exploring the /proc/net/ Directory

BSD Tricks: Linux Compatibility, the Hard Way


Discuss this article in the O'Reilly Network Linux Forum.

Return to the Linux DevCenter.

 




Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!


Linux Resources
  • Linux Online
  • The Linux FAQ
  • linux.java.net
  • Linux Kernel Archives
  • Kernel Traffic
  • DistroWatch.com


  • Sponsored by: