Xpra: Ticket #293: tune the audio queue latency so it is in sync with the video

As opposed to picture buffering, sound buffering is always done client side at present. It is less of a problem considering the lower bandwidth requirements for audio data. The xpra.sound.sink has a set_queue_delay method (delay in ms).

Since r2938 the delay is hardcoded at 80ms, though this can be changed using the XPRA_SOUND_QUEUE_TIME env var.

What we should do instead, is calculate this delay using:

Difficulty:

Some pointers:

How you can help: provide samples of the damage and latency values with your setup. You should be able to get this info from the GUI's session info, though it is easier to record server-side data with:

xpra info |& egrep "^damage_out_latency|^client_latency"


Fri, 19 Apr 2013 13:51:00 GMT - Antoine Martin: status, milestone changed; owner set

hard, and I need more sample data, re-scheduling


Wed, 19 Jun 2013 04:28:41 GMT - Antoine Martin: milestone changed

r3655 should take care of sound jitter problems client side (speaker) r3656 does the same thing server side

I guess this means that tuning the latency is a little bit less important (re-scheduling that)


Thu, 20 Jun 2013 07:53:31 GMT - Antoine Martin:

r3664 improves this further by virtually restarting the server side pipeline: we drop all sound packets issued prior to us telling the server to increase its "sound sequence"


Wed, 03 Jul 2013 12:24:29 GMT - Norman Rasmussen: cc set


Tue, 16 Jul 2013 05:52:50 GMT - Antoine Martin:

Many more improvements have been made, see:

So this ticket is now even less of a priority.


Fri, 01 May 2015 06:45:05 GMT - Antoine Martin: status changed; resolution set

Will follow up in #835.


Sat, 24 Oct 2015 05:00:33 GMT - Antoine Martin: milestone changed

(fix milestone)


Sat, 23 Jan 2021 04:50:49 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/293