How to fix 0.2s audio delay in QubesOS?

Rel4967 · May 7, 2024, 2:53am

Does anyone else have problems with their audio and video being out of sync? Has anyone found a solution to fix or reduce the audio delay issues in qubes?

I’m currently using pulseaudio in kde with 4.2.1, but the problem seems to also persist for pipewire. Manually adjusting audio delay doesn’t seem to have any effect.

apparatus · May 7, 2024, 4:23am

github.com/QubesOS/qubes-issues

Audio/video sync not as good as it should be?

opened 05:06PM - 11 Oct 15 UTC

qubesuser

T: enhancement help wanted C: gui-virtualization P: major

It seems that audio/video sync in Qubes is not quite perfect, and worse than nat…ive. Looking at A/V sync tests it seems the audio might be 50-100 ms delayed on my machine. I have only tested this subjectively (it seems a proper test would require special hardware that I don't have at least right now) so it's entirely possible it's actually fine, although looking at the code there seems to be ground to expect that there is a problem. # EDIT: Latency introduced by Xen I didn't realize this when I filed this issue, but the biggest issue is in fact that Xen is causing PulseAudio to have lots of latency compared to Xen-less Linux due to lack of suitable real time behavior, even with only dom0 running. # Latency/timestamps issue One possible issue is that it seems that the latency of the host sound card (as apparently seen by running "pacmd list-sinks" in dom0) is not passed to the VM, and the VM does not pass timing information to dom0. In contrast, PulseAudio sink module-esound-sink asks the server to provide a latency number and feeds it back to PulseAudio, while sinks like module-rtp-sink send timestamps over the network. So it looks like the protocol should be changed to either send the latency from dom0 to VM (ideally every time it changes), have the VM send timing information and using it in dom0 to sync the audio or preferably both. The idea is that if dom0 reports 200ms latency, a movie player can send audio with a +200ms timestamp, sleep 200ms, and then start showing video, and it should be synced with the audio (the media player and PulseAudio should handle this automatically, provided that timestamps and latency data are passed properly between the VM and dom0 PulseAudio instances). I'm not sure what the exact impact of this is, although on my machine the internal sound card apparently has 125ms latency, which would be a significant issue if not handled properly. # Buffer size issue It seems the low latency option selects a 4096 buffer size, but 44100 s16 2-channel audio like Qubes is using is 176400 B/s, so 4096 bytes are 1/43 of a second, which is lower than the 60 Hz of typical video output, but higher than 25-30 fps of typical movies. So it might make sense to reduce to 2048 or even 1024, although ultimately the buffer size only matters for interactive workloads like games, while movies can just buffer a lot in advance (assuming the system is properly implemented). I think this should not be a significant issue, but it's a trivial fix so it might be worth considering. # VSync not exposed issue The GUI daemon protocol doesn't seem to tell VMs when vsyncs happen or allow to wait for host vsync, which means that the video will have a random 0-16 ms delay that the VM has no way of knowing, even if gui-daemon displays it instantly. I think this should also not have very significant impact and it's probably not trivial to fix. # Anonymity issues Sending latency and allowing to wait for vsync allows for inter-VM correlation, but there are already lots of other ways to do so. It might still be a good idea to allow to disable these for anonymity-sensitive VMs.