Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19

[Florian Schmidt <mista.tapas@gmx.net>]

On Wed, 1 Dec 2004 23:09:16 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> but ... this brings up the question, is this a valid scenario? How can
> jackd block on clients for so long? Perhaps this means that every audio
> buffer has run empty and jackd desperately needed some new audio input,
> which it didnt get from the clients, up until after the xrun? In theory
> this should only be possible if there's CPU saturation (that's why i
> asked about how much CPU% time there was in use).
> 
> One indication that this might have been the case is that in the full
> 3.5 msecs trace there's not a single cycle spent idle. But, lots of time
> was spent by e.g. X or gkrellm-4356, which are not RT tasks - so from
> the RT task POV i think there were cycles left to be utilized. Could
> this be a client bug? That seems a bit unlikely because to let jackd
> 'run empty', each and every client would have to starve it, correct?

actually a single client doing nasty (non RT) stuff in its process()
callback can "starve" jackd. AFAIK jackd waits until the last client has
finished its process callback. So, if some client's process callback
decides to use (for example) some blocking system call (big no no) and
consequently falls asleep for a relatively long time, then it can cause
jackd to miss its deadline. I'm not sure though wether this triggers an
xrun in jackd or just a delay exceeded message.

flo