694815 - Investigate audio latency in updated audio drivers

Status: RESOLVED INCOMPLETE

(Core :: Audio/Video: cubeb, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

We'd like to characterize the audio latency in the current/to-be-current audio drivers, and if needed provide a mechanism to run the drivers in a minimum-delay mode (without causing underflows).  This may well need to be adaptive to the hardware, etc, if it isn't already.

Matt, can you update this with your belief (or numbers!) on delay in the current and/or upcoming code and on what hardware/OS?  Thanks

Comment 1

[Ralph Giles (:rillian)]

I don't have measurements, but playing with

parec --latency-msec=15 | paplay --latency-msec=15

15 milliseconds was about the minimum delay setting I could achieve. Passing --latency-msec=10 or lower resulted in a longer delay, rather than a shorter one, whatever the actual delay was. 30ms end-to-end wasn't unreasonable for what I was hearing though.

This was recording from a usb webcam's microphone (046d:0821 Logitech, Inc. HD Webcam C910) and playing back on the motherboard soundcard (Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)). Linux, Fedora 15 on x86_64.

Comment 2

[Jean-Marc Valin]

I'm not sure parec/paplay is the best way to measure delay. In any case, I think the real issue here is *not* audio drivers or even audio hardware, but scheduling latency. You can easily get sub-millisecond latency with many drivers/soundcards I know (some quite cheap), but there's no way you can get this with a user-space application unless (at the very least) it runs with real-time priority. Is this something we're willing to assume?

Comment 3

[elthariel]

I think this latency (+-20ms) won't be achievable on every box on Windows. ASIO drivers are needed to reach this but they are generally available only for pro/semi-pro soundcards.

IIRC, 100ms+ latencies using MME or DX APIs on Windows are more like a starting point.

On linux, it will depends on the scheduling priority the process can get. 15ms latency without glitches needs real time priority and even sometimes a specific kernel.


On the other hand, alsa reports buffer underruns and i guess win32 api might do the same so it should be possible to automatically discover the right configurations options for the soundcard.

(I've just seen the last update on this bug was half a year ago, so excuse me if this is no longer relevant)

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

overtaken by events