Andrew, Thanks for all the work you've done in this area. I am one of the JACK developers. I noticed many of the problems discussed in this thread, but since I am still running 2.6.0, my experience may not represent the best currently available version. I will gladly build whatever version you recommend for comparison purposes. Overall, the unpatched 2.6 kernel has *much* better latency characteristics than did 2.4. But, running the JACK applications that I normally work with, it is still noticeably less responsive than 2.4 with your low-latency patch set (which runs very well indeed). Andrew Morton <akpm@xxxxxxxx> writes: > I'll do some more checks on 2.6 but as far as I know, it's performing OK. > If Jack is indeed running with realtime policy I'd be suspecting that > something other than the normal spends-too-long-in-the-kernel problem is > occurring. > Could someone give me a really simple description of how to obtain Jack, > and how to get it going sufficiently to demonstrate these problems? You can download JACK via our web site... http://jackit.sourceforge.net It is not difficult to compile and install. Quoting from the web site... JACK is a low-latency audio server, written for POSIX conformant operating systems such as GNU/Linux and Apple's OS X. It can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. Its clients can run in their own processes (ie. as normal applications), or can they can run within the JACK server (ie. as a "plugin"). JACK was designed from the ground up for professional audio work, and its design focuses on two key areas: synchronous execution of all clients, and low latency operation. These two focus areas place strong demands on the OS scheduler. During each audio period, the JACK server's SCHED_FIFO thread and one for each client process must be dispatched without much delay. Typical period sizes range from 64 frames (1.333 msec) to 2048 (42.667 msec). With a tuned system including a patched 2.4.19-ll kernel, I can run a 32-frame period (0.667 msec), though not without occasional xruns. To run JACK SCHED_FIFO, start it with the -R parameter. For this to work, you need access to realtime privileges. There are several methods, all described in the web site. The simplest (and least secure) is to run as `root'... # jackd -Rv -d alsa -p256 -r48000 You need the ALSA sound driver for your audio device configured and installed (not difficult with 2.6). For documentation, see... http://www.alsa-project.org The -p option sets the "period size" in frames, -r sets the sample rate in frames per second. These parameters determine the basic audio subsystem cycle time (period-size/sample-rate). Common sample rates are 44100 frames/sec (for CD) and 48000 (for DAT). The simplest JACK client to configure for playback is probably alsaplayer (though there are many others). http://www.alsaplayer.org Unfortunately, if you run the JACK daemon as root you must also run all its clients that way. This is one reason why we don't recommend that method. But, it will serve to demonstrate the latency problem. After jackd starts, type this in another window... # alsaplayer -o jack somefile.wav While the file is playing, try changing workspaces on the X display. I find that with 2.6.0 and -p1024 (a 21.333 msec cycle) this works OK until I switch to a workspace with a heavily loaded web browser (I generally use galeon). On a lowlatency 2.4 kernel this is solid as a rock, even with a much small period size. If I can be of any assistence, don't hesitate to ask, -- joq
