Subject: Re: [linux-audio-user] Which kernel for low latency and kernel 2.6.1-mm# problems
From: Jack O'Quin (joq_AT_io.com)
Date: Thu Jan 22 2004 - 00:56:05 EET
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_AT_osdl.org> 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...
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...
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).
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
This archive was generated by hypermail 2b28 : Thu Jan 22 2004 - 00:55:50 EET