RealtimeKit and the audio problem

The application is real-time. It is in full control, not the OS. When it knows it needs to fill an audio buffer, it does that. When it knows it needs to write a sample to disk, it does that. When it knows it has nothing better to do with its time for a little while, it lets the kernel do some stuff.

You are being OS centric. Let's be perfectly clear here: the OS is unimportant. It doesn't matter, at all. Linux, Windows, Solaris, OS X, they're all totally and absolutely irrelevant. The fact is, a computer is only useful for running applications, be they your eCommerce server solution, your audio recording apps, or telecommunications/GSM phone app. The only reason we even run had an OS at all is for convenience: it's easier to be able to run a couple apps together rather than having to reboot to change apps, it's cheaper to use a single computer to run your browser and email client at the same time rather than needing two computers, it's cheaper to let six students share a single mainframe rather than each needing their own, etc. We put a lot of effort into making these OSes powerful and pleasant to use, but at the end of the day, the OS is only there to run our applications.

When the application developers have to start bending over backwards to appease the OS instead of having the OS bend over backwards to run the application the way it needs to be run, something is wrong. It's like selling your car for gas money: you give up something you need in exchange for something you then suddenly no longer need. Without the applications, the OS is entirely freaking useless.

Therefor, if Linux is incapable of knowing what the audio applications want and can't automagically optimize appropriately, the solution is very simple: let the applications tell Linux exactly what they need and how they need it. Which is exactly what real-time systems in the kernel (and other related facilities) are meant to do.

If you dislike the security implications of those facilities, DON'T USE THEM. The audio folks don't give two shits about good server security or what not, because they're not running servers or multi-user desktops or even Web-based network-centric applications. They're running a dedicated set of audio processing apps and little else, and anything else they are running can quite safely be shoved into the background and starved of any CPU or I/O time while the audio app is doing its thing.