measuring audio latency?

[Roderick Colenbrander]

On Tue, Mar 9, 2010 at 11:00 AM, Maarten Lankhorst
<m.b.lankhorst at gmail.com> wrote:
> 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
>
>
>

I might be able to measure it using my oscilloscope. Somehow I would
need to play lets say the left channel 'without' latency and the other
channel with and compare the two signals.

Roderick