Messages in this thread | | | Date | Wed, 1 Dec 2004 23:09:16 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19 |
| |
* Rui Nuno Capela <rncbc@rncbc.org> wrote:
> Here goes attached the captured latency traces for you to check. I > guess this time xmms-jack its at stake 'coz it was the cherry on top > of the cake, for three times in a row :)
the latency does seem to be related to clients, as in the following trace:
xruntrace1-2.6.10-rc2-mm3-RT-V0.7.31-19-20041201202926.trc
jackd-16714 goes into sys_poll() at timestamp 0.850ms, and does a pipe related wait:
jackd-16714 00000000 0.853ms (+0.000ms): pipe_poll (do_pollfd)
and goes to sleep:
jackd-16714 00000000 0.857ms (+0.000ms): schedule_timeout (do_poll)
almost 3 milliseconds later, at timestamp 3.404ms, the pipe related timer expires and jackd gets scheduled again:
ksoftirq-3 00000000 3.403ms (+0.000ms): wake_up_process (run_timer_softirq) ksoftirq-3 ........ 3.404ms (+0.000ms): -> jackd-16714 [ 00000027 00000003 ]: try_to_wake_up
obviously an xrun has happened during this 2.6 msec wait:
IRQ 5-3078 00000000 2.277ms (+0.000ms): xrun (snd_pcm_period_elapsed)
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?
anyway, your plan to try jack_test3.1 again looks like the correct approach: we first need to check the behavior of 'trivial clients', before more complex scenarios with real clients can be considered.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |