| |||||||||||||
DBusDBusPosted Jul 2, 2009 2:06 UTC (Thu) by dmarti (subscriber, #11625)In reply to: RealtimeKit and the audio problem by jwoithe Parent article: RealtimeKit and the audio problem Would it work to have the distribution bundle a simple utility that would do the necessary D-BUS communication, then exec(3) the real application?
(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
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
|
|||||||||||||