Re: 2.6.19-rc6-rt8: alsa xruns

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Fernando Lopez-Lezcano <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux