On Tue, Mar 9, 2010 at 11:00 AM, Maarten Lankhorst <m.b.lankho...@gmail.com> wrote: > Hi Dan, > > 2010/3/9 Dan Kegel <d...@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