Bugzilla – Bug 5590
reduce latency for audio
Last modified: 2016-12-07 13:18:34
You need to
before you can comment on or make changes to this bug.
The latency for our audio tunnel is getting a bit annoying with bug 4194 in
place. You have a noticeable delay between pressing something and getting the
audio event. Video players also struggle a bit before they get things in sync.
We should see if we can reduce this latency to more manageable levels. We
probably also need to investigate rewind handling, as that can hide a lot of
Hmm... Seems to be a lot better after upgrade to 6.0 (bug 5589). With a Fedora
client I have a latency of 70 ms, which is really good. Will have to
So I've done a preliminary study of the issue. These are the backends we use:
- (old) tunnel: Fixed latency of 250 ms. Crappy handling of latency in
general. No rewind support. No point in doing much though since its being
- new tunnel: dynamic latency after fixes in bug 5589. Will be as low as is
possible. No rewind support though, and will glitch when compensating for a too
- ALSA: full dynamic latency and rewind support. Pretty much as good as it
- OSS: Haven't checked. Probably not very good. Few things use this module
- waveout: fixed latency of 200-250 ms, no rewind support. Decent feedback but
needs more features to get the latency down.
- coreaudio: fixed latency of 12 ms, no rewind support. A bit suspicious with
the low latency, but it seems to be somewhat correct as video syncs properly.
Still needs to be dynamic to get low buffers though.
The new tunnel modules are also used on the server, so the limitations of those
modules affect every session, on top of the client backend.
Some numbers for the above. This was done using a Fedora 22 server, using
Firefox' video player and youtube. PulseAudio reconfigures itself depending on
the latency requested by clients, so you have to use the same applications in
order to properly compare numbers.
Client Client Server Server
Latency Buffer Latency Buffer
Linux (F22, PulseAudio): 10ms 30ms 40ms 100ms
Windows (8.1): 230ms 200ms 450ms 320ms
OS X (10.10): 12ms 300ms 300ms 300ms
armv5l: 140ms 120ms 250ms 170ms
armv5hl: 300ms 300ms 600ms 400ms
(Xubuntu 13.10, PulseAudio)
The numbers are the reported sink latency and stream buffer seen in the
client's pulseaudio server and the sessions pulseaudio server. The sink latency
on the server end should be roughly the sum of the client's sink latency and
the client's buffer.
The total latency perceived will be the sum of the last two numbers. If we had
rewinding then we could probably get the perceived latency close to the network
So, the most obvious improvements we can make are:
- Dynamic latency for waveout and coreaudio. waveout might need to be replaced
with the new audio API on Windows (bug 2831?)
- Glitch free dynamic latency in the new tunnel modules.
- Rewind support in every backend except ALSA.
(In reply to comment #3)
> The total latency perceived will be the sum of the last two numbers. If we had
> rewinding then we could probably get the perceived latency close to the network
This is not entirely correct. That's the perceived latency for that particular
stream (Firefox in this case). This might be fine for that particular
application, but not for others.
The more important number is the server side sink latency. This is the minimum
latency any other application will see. E.g. if a terminal wants to beep whilst
Firefox is playing.