Messages in this thread | | | From | Jay Ts <> | Subject | Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0 | Date | Fri, 12 Jan 2001 19:45:43 -0700 (MST) |
| |
Andrew Morton wrote: > > Jay Ts wrote: > > > > Now about the only thing left is to get it included > > in the standard kernel. Do you think Linus Torvalds is more likely > > to accept these patches than Ingo's? I sure hope this one works out. > > We (or "he") need to decide up-front that Linux is to become > a low latency kernel. Then we need to decide the best way of > doing that. > > Making the kernel internally preemptive is probably the best way of > doing this. But it's a *big* task
Ouch. Yes, I agree that the ideal path is for Linus and the other kernel developers and ... well, just about everyone ... is to create a long-range strategy and 'roadmap' that includes support for low-latency.
And making the kernel preemptive might be the best way to do that (and I'm saying "might"...).
But all that can take years, if it happens at all, and we may have a short-term approach that will satisfy almost everyone, at least for now, and maybe even allow for the development and maybe even (?) commercial distribution ("shrink wrap") of audio software for Linux. (Er, assuming that the ALSA drivers become the standard audio drivers. Mustn't forget that.)
As for actually desiring a preemptive kernel, I'm not a complete expert in this area, but I will say that no one has ever managed to explain to me why the extra complexity is vital, necessary, or just worth the bother. Sure, it would help with the implementation and OS support of the multithreaded and realtime code that I'm developing. So far, I haven't run into any major limitations yet related to lack of a preemtive kernel, but maybe I will later. (?)
> I could propose a simple patch for 2.4 (say, the ten most-needed > scheduling points). This would get us down to maybe 5-10 milliesconds > under heavy load (10-20x improvement).
5-10 ms wouldn't be great, but would at least be better than nothing. It would be a good start, perhaps, especially if it were understood that things will get better later on. As with the development of SMP support for Linux.
> That would probably be a great and sufficient improvement for [...] > people who are only interested in audio record and playback - I'd need advice > from the audio experts for that.
Well, call me an audio expert, then. :) What sort of advice do you want? You can send your comments to the LAD (linux audio development) mailing list, and there are a bunch of smart audio/music programmers who I'm pretty sure will be happy to comment.
One thing I'd like to say is that simple recording and playback of audio is hardly the complete picture! Try recording and playback of *many* channels of audio, while at the same time running multiple software synthesizers and effects plugins, and recording and playing back MIDI sequences. And other things, too. One thing I ask of anyone who's developing Linux is to please think in an open-ended manner regarding audio/music. This is really still a pretty new and immature field, and the software (when the Real Stuff gets to Linux, that is) will be happy to absorb whatever hardware resources are thrown at it for years to come.
> I hope that one or more of the desktop-oriented Linux distributors > discover that hosing HTML out of gigE ports is not really the > One True Appplication of Linux,
I agree approximately 110.111%. :) Really, I find servers to be pretty boring. "Linux is supposed to be fun", right? :)
> > What's the prob with XF86 4.0? > [snipped longish explanation] > So, we need to talk to the xfree team. > > Whoops! I accidentally Cc'ed them :-)
Thank you. A low-latency kernel would be meaningless if the X server creates delays of 20ms! This just plain needs to be fixed.
- Jay Ts jayts@bigfoot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |