xpra icon
Bug tracker and wiki

Opened 8 years ago

Closed 6 years ago

Last modified 21 hours ago

#293 closed enhancement (duplicate)

tune the audio queue latency so it is in sync with the video

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 0.16
Component: client Version:
Keywords: Cc: norman@…


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:

  • the picture encoding latency (which we already have)
  • adding the picture decoding latency (which the client obviously has access to)
  • substracting the server sound encoding latency (TODO)
  • substracting the client sound decoding latency (TODO)
  • Average it, add some minimal value clamping, etc.


  • we do buffer in the pipelines, so this must be excluded (but we don't necessarily know which value was used by the time we reach the end of the pipeline, it may have changed.. maybe count each side of the queues separately?)
  • we can and do drop packets as needed..

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"

Change History (8)

comment:1 Changed 8 years ago by Antoine Martin

Milestone: 0.90.10
Owner: set to Antoine Martin
Status: newassigned

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

comment:2 Changed 8 years ago by Antoine Martin

Milestone: 0.101.0

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)

comment:3 Changed 8 years ago by 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"

comment:4 Changed 8 years ago by Norman Rasmussen

Cc: norman@… added

comment:5 Changed 8 years ago by Antoine Martin

Many more improvements have been made, see:

So this ticket is now even less of a priority.

comment:6 Changed 6 years ago by Antoine Martin

Resolution: duplicate
Status: assignedclosed

Will follow up in #835.

comment:7 Changed 5 years ago by Antoine Martin

Milestone: 1.00.16

(fix milestone)

comment:8 Changed 21 hours ago by migration script

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

Note: See TracTickets for help on using tickets.