On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
