[linux-audio-dev] Linux 2.6 not a latency panacea?

[Kai Vehmanen]

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!