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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Reply via email to