On Fri, Feb 25, 2011 at 10:29:45AM -0500, Paul Davis wrote: > On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <l...@samalyse.com> 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@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev -- torben Hohn _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev