LWN: Comments on "Low latency for audio applications"

Low latency for audio applications

farnz — Thu, 03 Feb 2005 17:52:11 +0000

There is no way for the kernel to accurately gauge the needs of a real-time application. Given a simple enough case, the developers of the application can determine what it needs, and require that users set the cap high enough, but in the general case, this is not possible.

No matter what the kernel does, if you want more CPU power than is available, you're doomed; all the isosynchronous patches do is limit the available CPU power to less than flat-out, allowing an admin to recover if a realtime process runs away. The solution is the same as in any other realtime system; get a faster processor.

Low latency for audio applications

acristianb — Thu, 03 Feb 2005 17:10:05 +0000

Real time apps need realtime processing. They do not care if that takes 50% or 70% of the CPU. I think the isoschmiso classes are just teasing the apps in that they are promising them CPU bandwith but not realy guaranteeing that. I think a better approach would be to measure what are the needs of a realtime application and compute at application start time if a CPU bandwidth can be guaranteed for it and if not to exit right there with an error message or start NORMAL and notify the user of this.

Low latency for audio applications

mwalls — Thu, 27 Jan 2005 17:29:41 +0000

Another group that really cares about these patches are the video people (mythtv and relatives). Same problem even greater CPU load issues.

Low latency for audio applications

farnz — Thu, 27 Jan 2005 10:55:52 +0000

It is rocket science; if his app exceeds 100% CPU usage, he's not getting what he wants, and there's nothing a better kernel can do about it. As exceeding 100% CPU is going to lock up his machine, the patch allows a musician to set a limit, and then if his realtime applications are going to lock his machine up, the kernel drops their realtimeness, thus giving a musician a chance of recovering. Without this mechanism, the machine can lock hard, and there's no way to discover why, or to recover.

As a simple example of when this helps; a soft synth is normally a realtime application (MIDI in -> Waveform out). When running, a soft synth doesn't take that much CPU; if it did, it wouldn't work. If your algorithm fails, and causes the synth to run away in an endless loop (bad validation of input MIDI data, for example), you're doomed if it can take 100% CPU. If all your RT tasks are limited to 95% CPU between them, you can fire up "top", notice that the soft synth has gone from around 5% CPU to around 90% CPU, and kill it.

Low latency for audio applications

gnb — Thu, 27 Jan 2005 09:54:21 +0000

Because you need to say what it is you want. If there isn't enough CPU
to meet all requirements, someone needs to decide on a trade-off and
not all users will want the same things: should the RT apps remain
RT even if this makes all the non-RT ones completely unuseable? Surely
the user should make that decision rather than the kernel? Or, as other
people have more concisely put it, the kernel provides mechanism, not
policy.

Low latency for audio applications

alonso — Thu, 27 Jan 2005 08:48:37 +0000

Set the limit at 100%... and be happy

Low latency for audio applications

xorbe — Thu, 27 Jan 2005 07:12:49 +0000

Except that, a musician is not going to be happy when his
app exceeds "80%" and gets dropped back into the normal
realm of scheduling. How come these people can't just be
fed a kernel that does what they want? It's not rocket
science.