Low latency for audio applications

The idea of merging the realtime module appears to have been dropped for now; the opposition was too strong. There are a couple of other approaches which are being worked on, however, to meet the audio developers' needs. In particular, Con Kolivas and Ingo Molnar have been creating patches, and audio hacker Jack O'Quin has been tirelessly testing them out. Two approaches which look like they could solve the problem have emerged from this work.

The approach taken by Con Kolivas is the isochronous scheduler patch. This patch, in its current form, creates two new scheduling classes: SCHED_ISO_RR and SCHED_ISO_FIFO. These classes function much like the realtime scheduling classes in that they provide a higher scheduling priority than any SCHED_NORMAL process enjoys. They differ from the true realtime classes, however, in a couple of ways. No privilege is required to enter one of the isochronous classes, so audio applications need not run as root. The scheduler will also automatically select an isochronous class if an unprivileged application attempts to enter a true realtime class, with the result that many audio applications can use the new classes without modification.

The isochronous classes give high-priority access to the CPU, but only to a point. If isochronous processes use more than an administrator-defined percentage of the processor (70% by default), they get dropped back to the SCHED_NORMAL class for a while. This feature prevents high-priority, unprivileged tasks from taking over the system entirely. This is an important feature - the lack of any such protection was the reason for many of the objections to the realtime security module.

Ingo Molnar's approach, instead, is the creation of a new resource limit (initially called RLIMIT_RT_CPU_RATIO, later changed to RLIMIT_RT_CPU). This limit controls what percentage of the processor's time may be taken by all unprivileged realtime processes. If the limit is in effect, the patch also allows any process to enter the realtime scheduling classes. So the end result is similar to that obtained with Con's patch: unprivileged tasks can get realtime access to the processor, but they are prevented from taking over entirely. The difference is that Ingo's patch is somewhat smaller and simpler, and does not require the introduction of new scheduling classes.

The rlimit-based patch is also interesting in that it allows each process to have a different maximum CPU utilization limit. Imagine a system running a set of audio applications where some have their limit set at 60%, and others at 80%. If 70% of the available processor time is actually being used by realtime tasks, processes with the 60% limit will lose their realtime access, but the 80% processes will not. This scheme, thus, allows a smart supervisor (such as the jack server) to arrange for a (relatively) graceful degradation as contention for the CPU increases.

Jack O'Quin's benchmarking suggests that either patch, in their most recent forms, has the potential to solve the problem (though the realtime preemption work may also be required for a complete solution). He appears to favor Ingo's version, however, and its relative simplicity could well argue for taking that path. It does not seem that any decisions have been made, however; it may be that nothing is merged until the 2.6.12 process starts. It does appear, however, that life is about to get a little easier for Linux audio users, which is a good thing. It can be worthwhile to be noisy about your needs, especially if you are willing to put time into helping in the development of the solution.