On Fri, Feb 25, 2011 at 10:29:45AM -0500, Paul Davis wrote:
> On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <list@email-addr-hidden> wrote:
>
> > But let's take JACK for example. It handles setting up realtime scheduling
> > transparently when one creates a jack client. There isn't any extra step
> > necessary. As a supposition, could you imagine that ulatencyd integrates tightly
> > into JACK to provide fine-grained per-client realtime permissions?
>
> ulatencyd is, IMHO, a complete red-herring here. it has nothing to do
> with what JACK does. ulatencyd appearst to me concerned entirely with
> desktop latency and the notion that the "current app" (as represented
> by some form of ongoing user interaction) should be the most
> responsive. this has nothing whatsoever to do with the realtime
> scheduling that JACK is concerned with.
>
> specifically, what JACK does is per-thread, and more significantly its either:
>
> * for threads that it creates (inside libjack) AND knows that they
> need to be RT
> * for threads that the client specifically asks to be RT
>
> you can't do this stuff on a per-process level.
also if cgroups on the system are properly configured, all the server
side needs to do is:
echo "$TID" >/mnt/cgroups/cpu/rt_goup/tasks
i dont think you need a lua interpreter for that :>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
-- torben Hohn _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-devReceived on Fri Feb 25 20:15:05 2011
This archive was generated by hypermail 2.1.8 : Fri Feb 25 2011 - 20:15:05 EET