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.
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.
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.
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.
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 > 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.
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: https://www.youtube.com/watch?v=ucZl6vQ_8Uo I tested using a CentOS 7 server with the XFCE desktop. Version 4.13.0 of both the client and the server.
