Bug 5590 - reduce latency for audio
: reduce latency for audio
Status: NEW
: ThinLinc
: pre-1.0
: PC Unknown
: P2 Normal
: MediumPrio
Assigned To:
  Show dependency treegraph
Reported: 2015-07-02 15:34 by
Modified: 2016-12-07 13:18 (History)
Acceptance Criteria:



You need to log in before you can comment on or make changes to this bug.

Description From cendio 2015-07-02 15:34:09
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
the latency.
------- Comment #1 From cendio 2015-07-03 12:31:06 -------
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
investigate more.
------- Comment #2 From cendio 2015-07-17 14:21:55 -------
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
low latency.

 - 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.
------- Comment #3 From cendio 2015-07-17 14:30:39 -------
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
(T410, PulseAudio)
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
------- Comment #4 From cendio 2015-07-17 14:34:28 -------
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.
------- Comment #5 From cendio 2015-07-17 14:40:13 -------
(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
> latency.

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.