On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <list(a)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.