RealtimeKit and the audio problem [LWN.net]

RealtimeKit and the audio problem

Posted Jul 2, 2009 0:27 UTC (Thu) by jwoithe (subscriber, #10521)
Parent article: RealtimeKit and the audio problem

Beyond the communication issues I think there were several reasons why rtkit didn't get a particularly favourable response from the LAD community.

Firstly, the rtkit solution requires that any application wishing to use rtkit becomes dependent on dbus. For many authors (particularly of software aimed more at professional use) this is not regarded as a good thing for a number of reasons (technical and otherwise).

Second, as was mentioned in the article, the RLIMIT_RTTIME limit was presented as "the answer" in the 2.6.12 days. Many of the shortcomings of RLIMIT_RTTIME were mentioned at the time RLIMIT_RTTIME came into existance. The stated solution to these was that userspace support of RLIMIT_RTTIME would take care of them. The problem is that the promised userspace support applications/daemons were never written. It is argued that instead of introducing yet another mechanism we should instead be concentrating on making RLIMIT_RTTIME work as it was intended. To take one example, one of the distributor's concerns about RLIMIT_RTTIME is that it grants RT scheduling functionality to all processes started by a given user. Technically though such a broad grant of the RT privilege isn't necessary as demonstrated by other userspace tools such as set_rlimits(*). The reason that it *is* an issue is because the integrated tools to make it happen don't exist.

Third, some developers have claimed (on the LAD mailing list) that in practice rtkit does not in fact protect the system against very much at all. I haven't evaluated the arguments in details but to my knowledge their concerns have not yet been addressed.

Forthly, many (but not all) developers on the LAD list are associated with software which is aimed more at the professional user than the typical "desktop" user. They see rtkit as something originating from the desktop scene which is being forced onto professional users without any thought as to what effect this might have on the pro users.

Finally, rtkit is Linux-specific while many audio developers support their software on a multitude of platforms and operating systems (both free and otherwise). Using rtkit introduces yet another point of difference that they have to manage across the supported systems - an overhead many, it seems, are unwilling to accept.

As a result of these and other issues aired on the LAD mailing list, many audio developers simply don't see rtkit as a viable solution to the audio problem from their point of view. As a result of the clearly polarised reception of rtkit I'm not entirely sure that "the audio community will eventually move to make use of it". My concern is that it will in fact further fragment the community - that we'll see developers of desktop applications embracing it while those of pro applications will not. This will hardly lead to an improved Linux audio experience all-round.

I certainly have no arguments with the motivating reasons behind the development of rtkit - setting up audio under Linux is problematic on a number of fronts and needs to be improved. While I can understand Lennart's frustrations and the reasons behind rtkit's structure I can't help but wonder whether discussing the basic problem with a *small* group of significant stakeholders representing both desktop and pro audio users might have resulted in a system which was acceptable to all.

(*) Disclaimer: I wrote set_rlimits.

(Log in to post comments)

DBus

Posted Jul 2, 2009 2:39 UTC (Thu) by jwoithe (subscriber, #10521) [Link]

No, I don't think so. For starters, the "real application" needs the ability to set RT scheduling as it sees fit, often on a per-thread basis. Having the "simple application" acquire a single RT priority on behalf of the "real application" before calling exec() is far too restrictive for many audio applications.

However, more importantly, even though the "simple utility" could get RT scheduling priorities (and permission to set them) from rtkit, the SCHED_RESET_ON_FORK flag would ensure that all this is lost across the exec() call. In this scenario the "real application" will never inherit the RT privileges.

Regards
jonathan

DBus

Posted Jul 2, 2009 4:34 UTC (Thu) by salimma (subscriber, #34460) [Link]

It should not be affected by SCHED_RESET_ON_FORK -- the wrapper will just exec, not fork.

DBus

Posted Jul 2, 2009 5:08 UTC (Thu) by jwoithe (subscriber, #10521) [Link]

Hmm, on reflection that is true - we're talking exec(), not fork().

However, there could be another issue. As I understand it, rtkit doesn't grant the requesting process permission to set an RT priority though sched_setscheduler(). Instead it grants a requested RT priority to the process. In other words it functions as a replacement for sched_setscheduler(). As I previously explained, many high-performance audio applications (for example, ardour, jack) are multithreaded and request different scheduling algorithms and priorities for different threads. The simple wrapper application would only be able to grant a single RT priority to what would become the audio application's main thread. That application (or any of its threads) would not be able to alter that priority (or maybe even drop RT scheduling).

Having a single global RT priority for all threads isn't flexible enough to ensure smooth operation of these applications (and in fact, in most cases only a few carefully chosen threads need to run at RT priority anyway).

Regards
jonathan