Bug 5590 - Audio latency annoyingly high in some cases
Summary: Audio latency annoyingly high in some cases
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Sound (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Pierre Ossman
Depends on:
Blocks: 2068
  Show dependency treegraph
Reported: 2015-07-02 15:34 CEST by Pierre Ossman
Modified: 2021-11-15 12:33 CET (History)
3 users (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2015-07-02 15:34:09 CEST
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 Pierre Ossman cendio 2015-07-03 12:31:06 CEST
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 Pierre Ossman cendio 2015-07-17 14:21:55 CEST
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 replaced.

 - 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 gets.

 - OSS: Haven't checked. Probably not very good. Few things use this module though.

 - 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 Pierre Ossman cendio 2015-07-17 14:30:39 CEST
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 latency.
Comment 4 Pierre Ossman cendio 2015-07-17 14:34:28 CEST
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 Pierre Ossman cendio 2015-07-17 14:40:13 CEST
(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.
Comment 8 Samuel Mannehed cendio 2021-11-04 14:46:43 CET
I am seeing major delays when using the client on Windows 10 and on Fedora 34. There is a big audio latency when playing audio files, playing games (tremulous) and using WebRTC web meeting apps (Google Meet, Skype, Jitsi).

Using "pactl list sinks" I could see major latency differences between the platforms:

     Platform     │ Latency (ms)
 Windows 10       │  500
 macOS 12         │  180
 IGEL UD3 (PA)    │  40
 IGEL UD3 (ALSA)  │  70
 Fedora 34 (PA)   │  600
 Fedora 34 (ALSA) │  180

As seen above, IGEL stands out, it works really well. Meanwhile Fedora is awful, could PipeWire be the reason?

Changing the "Sound system"-setting in the client options also has some impact, as seen above, especially on Fedora.

Video and audio sync works great inside the session running YouTube in Firefox:


I tested using a CentOS 7 server with the XFCE desktop. Version 4.13.0 of both the  client and the server.

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