[linux-audio-dev] n00b friendly latency tester

[Florian Paul Schmidt]

On Sat, 06 May 2006 20:35:07 -0400
Lee Revell <rlrevell at joe-job.com> wrote:

> > > Same as the existing CLI tools - it would start an RT thread that polls
> > > on the RTC, then tell the user to generate some load (switch windows,
> > > do a find /, pingflood the default gateway, whatever), then report back
> > > the maximum latency.
> > 
> > Could you give me some links to these tools? I know I've seen something 
> > like this, but I'm unable to find it...
> 
> I think Florian Schmidt's web site has the latest latency tester.
> 
> > How do these tools relate to the latency tracer in the realtime kernel?
> > 
> 
> The tester is a userspace tool to measure low latency performance, the
> latency tracer is an in-kernel mechanism to determine which part of the
> kernel might be causing a latency problem.

You can get the tarball from this page:

http://tapas.affenbande.org/?page_id=15

[Some elaborations for the OP]:

Of course, as this uses the RTC and not the soundcard it cannot account
for i.e. buggy soundcard drivers [i have a cs46xx card that _always_
produces some xruns no matter how well tuned the system is. No such
problems with my delta 66].

I kinda thought rtc_wakeup was obsolete these days, as the kernel tools
are a much better instrument [assuming you use a -rt kernel, or does
vanilla have the latency tracing et. al. stuff these days, too?]. So
maybe it is still useful for a non-rt kernel. But what serious audio
user would use a non-rt kernel?

On a 2.6.15.4 kernel with low latency desktop setting [non-rt] i
get a max jitter of [after like 5 minutes running]:

new max. jitter: 68.4% (667 usec)

which looks pretty good. But it seems jackd has some more weak points
than rtc_wakeup [which is very simple]. For example on this kernel
running jack with a periodsize of 256 at a samplerate of 48khz _seems_
to run fine even with a find / or two. But beware. Copying large files
to /dev/null makes jackd sometimes produce xruns in the range of tens to
hundreds of ms -> ugh. rtc_wakeup OTOH is not affected by this. I
suspect the culprit is the FS [which jack depends on through its use of
pipes to do the interprocess wakeup]. But only -rt instruments could
tell us what's really up.

It seems -rt kernels have the latency tracing mechanisms available even
when not using full preemption. But i'm too lazy right now ;)

Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org