Re: 2.6.19-rc6-rt8: alsa xruns

[Ingo Molnar <mingo@elte.hu>]

* Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

> > ok, i reproduced something similar on one of my boxes and it turned 
> > out to be a tracer bug. I've uploaded -rt10, could you try it? (The 
> > xruns will likely remain, but at least the tracer should be more 
> > usable now to find out the reason for the xruns.)
> 
> I'm testing -rt10 right now (your binary rpm). Looks like the number 
> and length of the xruns went down, at least for now. All below 2mSec - 
> jack is running 128x2 @ 48000Hz. I'll let it run for a while and 
> report the traces (I have a script that collects all traces above 
> 60us, but not all xruns trigger a trace).

ok.

How do you gather the traces, are you using manual control of tracing 
via prctl(0,1) / prctl(0,0) - or the built-in wakeup tracing method? The 
wakeup tracing method will detect fundamental problems in -rt 
scheduling, but other types of delays can be better debugged via 
explicit tracing. [jackd used to have the gettimeofday(0,1)/(0,0) hack - 
this API hack has been replaced by prctl(0,1)/(0,0) to start/stop 
tracing] Take a look at linux/scripts/trace-it.c on how to set up 
manually triggered tracing. [if you do that then all you need to do is 
to start/stop the trace - the kernel will do a maximum search and will 
record the longest delay between start/stop calls.]

Also, can you see the xruns/latencies with latencytest too? (That one 
might be easier to reproduce for me.)

Also, my experience is that if there's a short succession of latencies 
after each other, then it's usually the first trace that makes most 
sense to analyze - the others might just be 'followup' or 'secondary' 
delays caused by the tracing/printing overhead of the first trace. So 
generally i concentrate on the first trace. But if the traces are 
reasonably apart then each of them makes sense - and sometimes one trace 
is more informative than another.

	Ingo