RealtimeKit and the audio problem

Posted Jul 2, 2009 6:18 UTC (Thu) by aleXXX (subscriber, #2742)
Parent article: RealtimeKit and the audio problem

I didn't hear about "RealtimeKit" before, so maybe I missed some things.

My first impression is that it is not a solution.

* Why are cgroups not a good solution for that ? They can limit the share
of CPU time some threads get. I didn't understand what the problem is
with them.

* Why is a daemon called a "Kit" ? It seems nowadays every new thing is
some "FooKit", where each of those Kits replaces a well-known UNIX
mechanism with something undocumented nobody knows. It also seems that
everything which is called a "Kit" is kind-of implicitely accepted as the
new official standard way to do things.

* Where is the advantage of having a daemon which assigns RT priority to
processes if they ask for it over giving those processes the permission
to assign them RT priority themselves ? Isn't this just a big backdoor ?
Like a "friend" in a C++ class ? "I'm not allowed to do this, but I know
somebody who is, and he does everything for me I ask for" ?

* It is correct that SCHED_FIFO or SCHED_RR would be risky without
limitations. But this RealtimeKit looks like a big hack to get around
unsatisfying behaviour of the scheduler. There is a SCHED_EDF extension
to the normal Linux scheduler in development, where you can assign
periods and budgets to threads (which they cannot overrun). This looks to
me like a much better solution.

Alex

to post comments

RealtimeKit and the audio problem

Posted Jul 2, 2009 7:40 UTC (Thu) by Frej (guest, #4165) [Link] (3 responses)

I haven't heard anything about you, so maybe I really don't know anything about you!

* Why are you named "XXX"?. It seems nowadays that every new LWN comment is done by these "XXX" guy's, where each of those XXX guys replaces a well-known-respected kernel guy with someone nobody knows. It also seems that everyone who are called "XXX" is kind-of implicitly accepted as knowledgable people, who should be trusted on how to do things.

PS: I'm guilty of lame comments from time time as well ;). We all have bad days.

RealtimeKit and the audio problem

Posted Jul 2, 2009 8:43 UTC (Thu) by aleXXX (subscriber, #2742) [Link] (1 responses)

My subscriber number is smaller than yours ;-)

<neundorf AT kde.org> (google can tell you the rest)

P.S. this is not me: http://www.myspace.com/alexneundorfband (I didn't
know a second one exists)

RealtimeKit and the audio problem

Posted Jul 2, 2009 9:23 UTC (Thu) by Frej (guest, #4165) [Link]

I noticed ;) and therefore so much more surprised by the specific argument, so it deserved a bit of poking/humor/paraphrasing :).

Cheers!

Names

Posted Jul 2, 2009 9:56 UTC (Thu) by alex (subscriber, #1355) [Link]

Possibly because alex was already gone ;-)

RealtimeKit and the audio problem

Posted Jul 2, 2009 9:43 UTC (Thu) by nix (subscriber, #2304) [Link]

Your *Kit comment is not entirely accurate. HAL doesn't have 'Kit' in its
name anywhere!

(but, of course, DeviceKit, which might replace it unless it doesn't, is
a 'Kit'.)

As far as I can tell 'Kit' means 'should have a command-line interface
in /usr/libexec and decent manpages but we couldn't be bothered to define
any such thing or write any documentation at all, even one describing how
to set it up: your distro vendors will know through spending hours
grubbing through the code.[1] Here, use our k00l XML-dependent
communications mechanism of the week, which unlike the kernel's own
mechanisms provides no atomicity or delivery guarantees whatsoever and has
an extra layer of security which had horrible bugs for years because
nobody understands it.'

[1] this is unfair to Lennart, perhaps. If PA is any guide RealtimeKit
will have excellent docs. Unfortunately most of the others don't.
ConsoleKit is a particularly appalling example, or was last time I looked
at it.

RealtimeKit and the audio problem

Posted Jul 9, 2009 18:11 UTC (Thu) by jwb (guest, #15467) [Link]

FooKit is an interesting social phenomenon. It reflects the increasing influence of Mac OS X on free software developers. Everything in Mac OS X is called SomethingKit. DeviceKit, WebKit, whatever.

It used to be that Win32 weighed more heavily on the minds of free software. That's why you got HAL, a name directly taken from Windows NT.

RealtimeKit and the audio problem

Posted Oct 13, 2009 2:38 UTC (Tue) by MarkWilliamson (guest, #30166) [Link]

What you've said basically echos the stuff I was thinking when I read this - I don't really see from this article how having a userspace daemon is necessarily an improvement. Maybe there's more to it.

Having the kernel handle mechanisms and userspace daemons handle policy is a well established practice and a very sensible one. So having a daemon of some kind that sets up policy or can be consulted to make policy decisions seems reasonable. In this instance, though, it sounds like the userspace process is also handling part of the mechanism too. The kernel's machinery is apparently not suitable for applications to request realtime privileges, so that goes through the daemon too. This looks a bit awkward to me, as it suggests that a daemon has been created to compensate for a lack of kernel flexibility.