lkml.org 
[lkml]   [2006]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.19-rc6-rt8: alsa xruns

* 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
-
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/

\
 
 \ /
  Last update: 2006-11-29 20:57    [W:0.047 / U:11.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site