measuring audio latency?

[Maarten Lankhorst]

Hi Dan,

2010/3/9 Dan Kegel <dank at kegel.com>:
> Hey folks,
> before Maarten goes and implements wine audio
> on top of OpenAL, does anyone know of a nice
> automated tool for measuring audio latency
> that works on multiple APIs?  i.e. it'd be cool
> if one could plug in a loopback cable,
> run an app once, and get a report of the
> round trip audio latency with each of the available
> sound APIs in Linux or Win32 (or both), depending
> on how it was compiled.
>
> We'd want to verify that OpenAL scores as well as ALSA
> before doing the big rewrite, and we could use it as a
> manual regression test during the rewrite.
>
> I looked for such a thing, and recorded everything
> related to measuring audio latency on Linux or Windows at
> http://wiki.winehq.org/MeasuringAudioLatency
> but I didn't find my mythical test program.
>
> I'd write it myself, but my wrists are really shot...
I don't know about any automated way, but one could conceivably just
write a program that outputs a sound at a certain frequency and tries
to find that frequency back in the input. But it wouldn't be needed to
determine how much latency wine itself adds. You can deduce that by
simple math, since there is a upper bound on it. :)

For example current dsound adds 105 ms or 110ms, depending on whether
you use 44100 rate as primary, or 48000. OpenAL will probably use 4
buffers of 1024 samples, which would mean it adds 4096/44100 = 0.90s.
However if dsound uses it, and your OpenAL supports alBufferDataStatic
(OpenAL-soft currently doesn't), that would be a upper bound on the
latency, and if you really want you can make it even lower. But this
requires tinkering if you use alsa, since less than 3 periods is not
recommended for alsa dmix, and the default period size is fixed to
1024, unless you override it. :) OpenAL-soft's pulse will need some
patches, since for some reason it decided that if I lower the amount
of buffers, the latency would need to be increased to more than a
second which is very frustrating.

The latency wine adds is mostly because of scheduling, and with
wine-rt patches and realtime prio you can lower the latency wine adds,
but without it you just have too big a chance of underruns, which is
why wine adds so much latency currently, any underrun that occurs WILL
be heard, so I try to avoid that in the unconfigured wine case as much
as possible.

Cheers,
Maarten