[LAD] Realtime threads and security

Paul Davis paul at linuxaudiosystems.com
Fri Feb 25 15:29:45 UTC 2011


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



More information about the Linux-audio-dev mailing list