From linux-audio-dev Wed Aug 13 23:55:28 2003 From: Kai Vehmanen Date: Wed, 13 Aug 2003 23:55:28 +0000 To: linux-audio-dev Subject: Re: [linux-audio-dev] Linux 2.6 not a latency panacea? X-MARC-Message: https://marc.info/?l=linux-audio-dev&m=106081933804464 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!