Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

Lennart Poettering <mzynq@email-addr-hidden> 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 <ats@email-addr-hidden>                         <http://offog.org/>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev