Re: 2.6.19-rc6-rt8: alsa xruns

Ingo Molnar
2006-11-29T19:53:52Z

* 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