Xpra: Ticket #1103: reduce server side sound pipeline latency

Follow up from #849, #835, #1067.

We want to make the server side sound pipeline processing data as quickly as possible to reduce the latency. Maybe the XPRA_SOUND_QUEUE_SOURCE_TIME from #1067 made things worse.

Some pointers:



Thu, 28 Jan 2016 21:24:51 GMT - Antoine Martin: owner changed

See r11771 commit message. We can now tune the "buffer-time" and "latency-time". Note: unlike the underlying gstreamer property which uses microseconds, WE use milliseconds (just like everywhere else with the sound env vars).

We now change the defaults from 200/10 to 64/32. This can be seen with -d gstreamer server switch during sound source startup:

sound source default: buffer-time=200
sound source overriding with: buffer-time=64
sound source default: latency-time=10
sound source overriding with: latency-time=32
sound source initial actual-buffer-time: -1
sound source initial actual-latency-time: -1

This is applicable to pulsesrc, alsasrc, osssrc, oss4src at least (we use pulsesrc by default on posix), I will need to fix the win32 and osx shadow servers to get rid of the warning it is likely to generate there. (minor)

And we can now also see the actual values used via xpra info:

$ xpra info | grep client.speaker.actual-
client.speaker.actual-buffer-time=63990
client.speaker.actual-latency-time=31995

This value should probably be taken into account for av-sync (#835), and may explain some of the runtime discrepancies that have been observed.

The new environment variables introduced for fine tuning buffer and latency are:

XPRA_SOUND_SOURCE_BUFFER_TIME=64 XPRA_SOUND_SOURCE_LATENCY_TIME=32 xpra start ...

Notes:


@afarr: ready for testing so we can figure out if/how to use this:


Sat, 30 Jan 2016 03:25:09 GMT - alas:

Preliminary tests with Vorbis with 0.17.0 r11776 win32 client against 0.17.0 r11778 fedora 23 server...

(Suppose I'll also add details to #835 once they are more fully ... full.)


Sat, 30 Jan 2016 05:37:35 GMT - Antoine Martin:

..to the value of the sum of the buffer and the latency times...


That doesn't make sense: those two values are the lower and upper bounds of the source buffer. Taking the sum of both is meaningless, the average would make more sense. But even more so would be to look at the actual values used, as per comment:1 $ xpra info | grep client.speaker.actual-. Then add XPRA_SOUND_QUEUE_SOURCE_TIME.

Fixes for osx and win32 shadow servers in r12102.


Mon, 11 Apr 2016 02:18:02 GMT - Antoine Martin:

See ticket:1162#comment:2.

This is now disabled, but you may want to enable it if this runs well on your setup. Anything that lowers the latency is a good thing.


Fri, 02 Sep 2016 16:48:43 GMT - alas: owner changed

Ok, noted. I'll do a little testing on our end and see if it makes a noticeable difference.

If I notice anything worth mentioning I'll open a new ticket.

In the meantime, I'll pass this back to you to close, unless there's something more to do?


Sat, 03 Sep 2016 04:22:23 GMT - Antoine Martin: status changed; resolution set

Closing as wontfix since we're not using those tweaks at all.


Sat, 23 Jan 2021 05:15:03 GMT - migration script:

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