Hi Dan,
2010/3/9 Dan Kegel dank@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