Lennart Poettering <[email protected]> writes: > I just moved into Fedora Rawhide a little daemon called "RealtimeKit" > which will be enabled by default,
It would have been nice to see some mention of this on l-a-u/l-a-d earlier (i.e. while it was being designed), since getting realtime priority for audio applications is a problem that's been discussed and experimented with many times in this community. I'd imagine that most people reading this list are already using one of the existing solutions to this problem, and thus may be less delighted than you'd expect to have another mechanism dropped in their laps with no prior warning or chance to feed into the design process. ;-) I don't think it's a good idea to make the D-Bus interface the public API for this, because it assumes that you *can* write a D-Bus service that gives a thread in another process realtime priority (which is true for Linux, but not obviously so for other systems, even free ones). If you want to make it easier for people to write realtime applications, I think it'd be nicer -- and certainly more portable -- to provide a librealtimethread, which could try to call your D-Bus service if it's available, and otherwise fall back to the existing well-tested approaches for various platforms (e.g. by generalising the code from jackd). You appear to be heading this way with your example client code in rtkit anyway -- but please don't tell people to "copy these sources into your repository", particularly when they contain such blatantly unportable constructs as "#ifdef __linux__"! What it actually cares about is whether the D-Bus client library is available, which'd be easy enough to have a configure script test for. You also need to be careful about licensing. The license status of D-Bus -- at least, as of 1.2.14 -- is a mess: the daemon and libdbus-1 are dual-licensed under the Academic Free License 2.1 and the GNU GPL v2 (only). rtkit-test.c claims to be GPL v3 or later, which isn't possible, since neither the AFL 2.1 or the GPL v2-only are compatible with that according to the FSF <http://www.gnu.org/licenses/license-list.html>. The best solution would be for the D-Bus folks to relicense their client library under a more sensible permissive license... (Incidentally, why the "-Kit" naming? There seem to be a few packages like that around now, mostly providing a D-Bus service of some kind.) Thanks, -- Adam Sampson <[email protected]> <http://offog.org/> _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
