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

[Ingo Molnar]

* Florian Schmidt <mista.tapas@xxxxxxx> wrote:

> On Wed, 1 Dec 2004 23:09:16 +0100
> Ingo Molnar <mingo@xxxxxxx> 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.

since the period size in Rui's test is so small (-p64 is 1.6 msecs?),
the 2.6 msec timeout in pipe_poll() already generates an xrun.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/