Audio latency goes full circle

The rlimit approach keeps a rogue process from taking over the system entirely. It does not, however, prevent abuse by poorly-behaved software. If even limited access to realtime scheduling became widely available on Linux systems, it would only be a matter of time until developers figured out that they could make their programs seem faster by using the realtime mode. Proprietary applications could be particularly problematic in this regard; distributors would likely rip out unwarranted realtime scheduling calls in free software that they ship, but that cannot be done with proprietary code.

Other concerns with the rlimit approach include the need for some audio applications to get fast access to the CPU even if they require 100% of the available time, and general unease with tweaking the scheduler for this use. The end result is that the rlimit patch has come back out of -mm, and Ingo has said:

Those who have been following the discussion will remember that the whole long thing began because certain kernel developers did not feel that the realtime security module (which gives members of an administrator-specified group access to realtime scheduling) was acceptable for inclusion. So the discussion has come back to where it started, and it appears that the realtime security module will be merged (though that had not happened as of this writing). Ingo apologized for the whole thing, explaining it this way:

One remaining problem with the realtime security module is that it gives audio users the right to monopolize the processor with any program they run, not just audio utilities. Making the audio programs run in a setgid mode might seem like a way around that issue, except for the fact that the GTK+ toolkit actively prevents things from working that way. The unfortunate result is that users must be given more privilege than they actually need. Most of the time, that should be acceptable; multi-user audio workstations are likely to be relatively rare.