Subject: Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Thu Aug 14 2003 - 02:55:28 EEST
On Wed, 13 Aug 2003, Joshua Haberman wrote:
> I am distressed. It was my understanding that the 2.5/2.6 kernel branch
> was undergoing significant scheduler and latency work, and that 2.6
> would eliminate the kernel from the list of obstacles of low-latency on
> Linux. It will have the preemptable kernel patch, the new scheduler,
> and all of Ingo Molnar's low-latency work. Claims were being thrown
> around that 2.6 would be the lowest-latency operating system on the planet.
Well, while there are plenty of nice improvements from lad perspective,
many fundamental problems/features are still present in 2.6.
> So how is it that we're in the 2.6.0-test series and people are
> complaining about audio skipping in **XMMS**, which uses three second
> buffers by default?? If people are getting skips from high-latency
> playback, what hope is there for low-latency audio?
Yup, fact that hasn't changed is that you need SCHED_FIFO to achieve any
kind of reliable low-latency audio operation. The problems with XMMS
skipping are - while still important - not directly related to the
low-latency case.
> A series of patches
> are coming from both Ingo and Con Kolivas attempting to address this,
> but the fact they are just now throwing around potential solutions
> erodes at my faith that they really understand the problem or how to
> solve it.
These might help the out-of-the-box behaviour (running audio apps without
SCHED_FIFO), but will never be good enough for the low-latency case.
> Is 2.6.x going to be suitable for low-latency (or even reliable
> high-latency) audio? Or is it going to be more of the same: patching
> the kernel, tweaking parameters, reading magical incantations, and
> hoping for the best?
I've done limited testing with 2.6.0-test2 on my laptop, and got fairly
good results. In my tests it performed nearly as good as my
2.4.19smp-lowlatency, which is promising (as smp is a big advantage in
this case).
So it looks good, but still you absolutely need SCHED_FIFO. And I'm not
aware of any developments in the kernel caps area, so we still probably
need to patch the kernel to allow user apps to enable SCHED_FIFO.
Yups, it would be great if someone of us would have the time and energy to
participate more closely in linux-kernel discussion, and even better, in
kernel development. We'd need someone to actively push low-latency
improvements to the kernel and keep the issue on the table.
For example, one new approach to the problem SCHED_SOFTRR, see:
http://www.xmailserver.org/linux-patches/softrr.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1729.html
It's unlikely to get something like this enabled by default in the vanilla
kernel, but we might be able to get a kernel option (no patching!). But,
but, as you can see from the discussion, they are talking about totally
different things (how XMMS/realplayer performs)...
... basicly a way to get benefits of SCHED_FIFO but without need for root
privileges. Now we just need to push these to the standard kernel somehow.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Thu Aug 14 2003 - 03:01:07 EEST