RealtimeKit and the audio problem

> you say kill disk I/O and network I/O

> what if you are using one of those for your audio? how is the system supposed to know?

Probably by PID number. I was under the impression that the Linux I/O scedualer was capable of prioritizing different things.

The disk access can almost always be delayed because of the nature of cache in ram. A system can't prioritize incomming network packets becuase you need to analyze the packet first to determine weither or not it's priority, but processes can be give priority on network access.

This is all stuff that is already in the kernel.

> it's a very different thing to say that the system should prioritize your audio over everything else than to say that the system shouldn't have 500ms pauses. the latter is something that everyone can agree to, the former is not.

Ya... Its more complicated then you think here, I think.

Very low-latency = low performance. A system that has very good low-latency behavior tends to be inefficient. This means reduced performance for web servers, file servers, database servers, encryption, etc etc.

So it's certainly not something everybody can agree on. So it has to be tunable. Which is the point behind having a configurable system were you can assign "realtime" performance to key processes at the detriment for the rest of the system.

Audio is just one of the many times you need to have good "realtime" performance.

Any time your having a computer interacting with the real world.. You can't pause real-life. You can't put events in a buffer and schedual things so that you can have good performance.. many times the computer needs to react to events outside of it's control in a timely manner.

Robot controls, scientific instrumentation, vehicle navigation systems, vehicle control systems, cell phones, VoIP devices, wallstreet stuff blah blah blah.

It'll be nearly impossible to make Linux ever perform "hard realtime" but certainly things can be improved to the point were the utility of the vanilla Linux kernel can be increased massively.

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.