Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default;
Desktop/audio RT developers, read this!
[Posted June 30, 2009 by corbet]
| From: |
| Paul Davis <paul-dDzkXPnfpdxaomM2pvQuqZqQE7yCjDx5-AT-public.gmane.org> |
| To: |
| Linux Audio Developers List <linux-audio-dev-cunTk1MwBs/CEJeg2xFRV2D2FQJk+8+b-AT-public.gmane.org> |
| Subject: |
| Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default;
Desktop/audio RT developers, read this! |
| Date: |
| Sun, 21 Jun 2009 11:09:12 -0400 |
| Message-ID: |
| <eb4b5e1d0906210809v6904141ev108ddf3753b5f661@mail.gmail.com> |
| Archive-link: |
| Article, Thread
|
On Fri, Jun 19, 2009 at 2:13 PM, Lennart Poettering<mzynq-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org>
wrote:
> Heya,
>
> Just a quick announcement:
>
> I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
> which will be enabled by default, and since it is now a dependency of
> PulseAudio and things work how they work this will then not only be
> available in Fedora 12 but also sooner or later in the other
> distributions as well, installed by default.
>
> So what does this do? It's a simple policy daemon that hands out
> SCHED_RR scheduling to normal user processes/threads that ask for it.
This appears to be a baroque mechanism designed to solve a problem
suspectible to vastly simpler solutions. Alternatively, one could see
it as a baroque mechanism designed to solve to solve a problem that
really needs a much more sophisticated solution (i.e. better
scheduling policies). Either way, it seems like something that makes
things more complex on every level, not less. Take a look at the code
in libjack/thread.c and compare and contrast what is necessary to get
a realtime thread on Linux (already) compared to OS X. You're adding a
new API for this that will not be backwards compatible beyond a kernel
change that has only just been made. I cannot imagine wanting to use
this mechanism. You also seem to have assumed that everyone agrees
that SCHED_RR is the correct policy, rather than SCHED_FIFO.
Reasonable people still disagree about this. Finally, as Chris said -
many of us are writing apps that target multiple platforms, and adding
a new dependency on non-POSIX systems like DBus in order to get done
things that are supposed to be possible with the POSIX API ... well,
it gives some of us a slightly wierd feeling at the very least.
--p
(
Log in to post comments)