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...
Hi Dan, 2010/3/9 Dan Kegel <dank(a)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
On Tue, Mar 9, 2010 at 11:00 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote:
Hi Dan,
2010/3/9 Dan Kegel <dank(a)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
On Tue, Mar 9, 2010 at 2:58 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
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.
Yes, absolutely, but it'd be good to make this measurement easy to repeat by anybody interested. To do that, let's just loop the audio output back into the audio input. The user will have to provide a loopback cable (or, worst case, put his mike right up to the speaker, and allow for a tiny bit of extra latency from that). - Dan
On Tue, Mar 9, 2010 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote:
On Tue, Mar 9, 2010 at 2:58 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
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.
Yes, absolutely, but it'd be good to make this measurement easy to repeat by anybody interested. To do that, let's just loop the audio output back into the audio input. The user will have to provide a loopback cable (or, worst case, put his mike right up to the speaker, and allow for a tiny bit of extra latency from that).
If sound travels at 340m/s, then a one-second sample is 340m long. A 1ms delay would therefore be 340mm, or 34 cm. Your mic would have to be *quite* far away from the speakers to have a significant impact on the delay, unless I'm missing something. Which is good news, I guess, since it means tests are easier. Hope it goes well :) Have fun, Avery
On 10 March 2010 10:01, Avery Pennarun <apenwarr(a)gmail.com> wrote:
On Tue, Mar 9, 2010 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote:
On Tue, Mar 9, 2010 at 2:58 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
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.
Yes, absolutely, but it'd be good to make this measurement easy to repeat by anybody interested. To do that, let's just loop the audio output back into the audio input. The user will have to provide a loopback cable (or, worst case, put his mike right up to the speaker, and allow for a tiny bit of extra latency from that).
If sound travels at 340m/s, then a one-second sample is 340m long. A 1ms delay would therefore be 340mm, or 34 cm. Your mic would have to be *quite* far away from the speakers to have a significant impact on the delay, unless I'm missing something.
You are: air pressure ;) hehe. Yeah, I know, it won't make a noticeable difference either; just being Devil's Advocate.
Which is good news, I guess, since it means tests are easier. Hope it goes well :)
Have fun,
Avery
On 9 March 2010 23:48, Ben Klein <shacklein(a)gmail.com> wrote:
On 10 March 2010 10:01, Avery Pennarun <apenwarr(a)gmail.com> wrote:
On Tue, Mar 9, 2010 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote:
On Tue, Mar 9, 2010 at 2:58 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
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.
Yes, absolutely, but it'd be good to make this measurement easy to repeat by anybody interested. To do that, let's just loop the audio output back into the audio input. The user will have to provide a loopback cable (or, worst case, put his mike right up to the speaker, and allow for a tiny bit of extra latency from that).
If sound travels at 340m/s, then a one-second sample is 340m long. A 1ms delay would therefore be 340mm, or 34 cm. Your mic would have to be *quite* far away from the speakers to have a significant impact on the delay, unless I'm missing something.
You are: air pressure ;) hehe. Yeah, I know, it won't make a noticeable difference either; just being Devil's Advocate.
Which is good news, I guess, since it means tests are easier. Hope it goes well :)
But if all you are interested in is the relative latency changes, then any additional latency effects should not matter as long as that latency added is constant. What is being checked is that the latency of wine+OpenAL is not noticeably greater than the current wine+ALSA implementation (that is, OpenAL has a latency that is at worst equal to ALSA as used by wine to within a certain tolerance for error). - Reece
On Wed, Mar 10, 2010 at 12:25 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote:
Yes, absolutely, but it'd be good to make this measurement easy to repeat by anybody interested. To do that, let's just loop the audio output back into the audio input. The user will have to provide a loopback cable (or, worst case, put his mike right up to the speaker, and allow for a tiny bit of extra latency from that).
But if all you are interested in is the relative latency changes, then any additional latency effects should not matter as long as that latency added is constant.
Right.
What is being checked is that the latency of wine+OpenAL is not noticeably greater than the current wine+ALSA implementation (that is, OpenAL has a latency that is at worst equal to ALSA as used by wine to within a certain tolerance for error).
Yes. Ideally we'd also run the app with other combinations as well (say, wine+OSS, or XP+ASIO, or Windows 7) to make sure we're not aiming too low. - Dan
On Tue, 9 Mar 2010, Dan Kegel wrote: [...]
Yes, absolutely, but it'd be good to make this measurement easy to repeat by anybody interested. To do that, let's just loop the audio output back into the audio input. The user will have to provide a loopback cable
Won't the DirectSound capture latency come into play too? Unless we are able to put a precise timestamp on each capture sample independently of when it gets to the Winelib application it seems to me that all we can mesure is the latency of the sound output + capture loop. If the total latency is low then we're in great shape. If it's too high then we should remember this and try to figure out how much each side contributes to the latency. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.
On Wed, Mar 10, 2010 at 8:32 AM, Francois Gouget <fgouget(a)free.fr> wrote:
Yes, absolutely, but it'd be good to make this measurement easy to repeat by anybody interested. To do that, let's just loop the audio output back into the audio input. The user will have to provide a loopback cable
Won't the DirectSound capture latency come into play too?
Unless we are able to put a precise timestamp on each capture sample independently of when it gets to the Winelib application it seems to me that all we can mesure is the latency of the sound output + capture loop.
That's right, but it's the best one can do without special hardware, I think.
If the total latency is low then we're in great shape. If it's too high then we should remember this and try to figure out how much each side contributes to the latency.
Right, that's the point at which we reach for the special hardware and/or more manual testing somehow. But the simple, automated, loopback test of total latency is definitely worth doing, IMHO. - Dan
Den 2010-03-09 11:00 skrev Maarten Lankhorst:
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.
I get 0.093s when I do the math... Cheers, Peter -- They are in the crowd with the answer before the question.
Why do you dislike Jeopardy?
On Tue, Mar 9, 2010 at 2:00 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote:
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.
No need for a frequency - a single pulse would do it, as outlined at http://manual.audacityteam.org/index.php?title=Latency_Test https://ccrma.stanford.edu/~matt/latencytest/ http://www.music.mcgill.ca/~ich/research/icmc01/latency-icmc2001.pdf
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. :)
That's fine in theory, but as Reagan said, "trust, but verify". There are a lot of probably's, if's, and but's in what you wrote, and many layers, so it's quite reasonable to want a simple automated check to actually measure the final latency. - Dan
participants (8)
-
Avery Pennarun -
Ben Klein -
Dan Kegel -
Francois Gouget -
Maarten Lankhorst -
Peter Rosin -
Reece Dunn -
Roderick Colenbrander