Xpra: Ticket #400: sound improvements - better queue handling, refactoring and cleanups
0.10 fixed a number of sound issues (ie: #362 and #379) but there is more we can and should do:
- refactor the code so both the client and server use the same logic for creating and destroying the pipelines (servers typiccally run on Linux so they tend to be more forgiving - but we still tend to play catch up with fixes already client side: #396)
- if the pipeline fails to start, we don't tell the client/server that requested it about the failure at the moment, which leaves a dead pipeline hanging. This is wasting cpu and showing the wrong state in the UI or "xpra info".
- the way we deal with overruns is to re-start the whole pipeline which is wasteful (and potentially problematic), we should instead use the fact that changing the
min-threshold-time (and maybe other attributes?) flushes the whole queue, effectively clearing the overrun
- choose the sound quality: stereo vs mono, 48KHz, etc..
- use a python wrapper to access pulseaudio rather than execing commands, one of:
Thu, 17 Oct 2013 07:43:55 GMT - Antoine Martin: owner, status, milestone changed
changed from Antoine Martin to Antoine Martin
changed from new to assigned
changed from 0.11 to 0.12
some minor improvements were made for 0.11, the rest should get done for 0.12
Mon, 03 Mar 2014 15:07:43 GMT - Antoine Martin: milestone changed
changed from 0.12 to 0.13
This is needed, but needs to be done early in the release cycle to find all the problems. Re-scheduling.
Fri, 09 May 2014 14:12:49 GMT - Antoine Martin: priority, milestone changed
changed from major to minor
changed from 0.13 to 0.14
Some cleanups were done as part of #90: see r6315, r6308, etc
Too late for the large refactoring.. so re-scheduling it again.
Thu, 28 Aug 2014 13:54:06 GMT - Antoine Martin: description changed
Fri, 29 Aug 2014 06:21:49 GMT - Antoine Martin:
See also: #663, #669 and #673.
Mon, 15 Sep 2014 10:04:11 GMT - Antoine Martin: description changed
Fri, 19 Sep 2014 14:40:50 GMT - Antoine Martin:
Started in r7700.
Tue, 23 Sep 2014 06:06:53 GMT - Antoine Martin: owner, status changed
changed from Antoine Martin to alas
changed from assigned to new
r7757 fixes this sink warning found on OSX:
pipeline warning: ['gstbasesink.c(3638): gst_base_sink_chain_unlocked (): \
Received buffer without a new-segment. Assuming timestamps start from 0.']
afarr: please check that I haven't broken anything on win32 or osx.
Tue, 23 Sep 2014 15:00:52 GMT - Antoine Martin: description changed
Mon, 06 Oct 2014 22:34:30 GMT - alas: owner changed
changed from alas to Antoine Martin
Sound still seems good, both OSX and Windows. SInk warning also gone.
Probably good to close this.
Tue, 07 Oct 2014 02:41:22 GMT - Antoine Martin: status changed
changed from new to assigned
I'm not closing this ticket yet because there are still quite a few items that I haven't dealt with.
Mon, 27 Oct 2014 19:28:31 GMT - Antoine Martin:
We can also deal with #669 and use multiprocessing.
Wed, 19 Nov 2014 22:54:40 GMT - Antoine Martin:
We can't use multiprocessing with pygst because it relies on the gobject / glib main loop exclusively - and we can only have on of those.
Tue, 10 Mar 2015 02:30:15 GMT - Antoine Martin: attachment set
set to sound-underrun.patch
deal with underruns better: try to use min-threshold-time
Tue, 17 Mar 2015 13:51:11 GMT - Antoine Martin:
The "sound underrun" patch has been applied as part of r8786 for #669.
This may affect underrun and overrun events...
Mon, 23 Mar 2015 17:19:12 GMT - Antoine Martin:
r8827 allows us to disable this new variable min queue code using:
XPRA_VARIABLE_MIN_QUEUE=0 xpra attach ...
Mon, 30 Mar 2015 10:31:13 GMT - Antoine Martin:
Some improvements in r8870 (see commit message).
Mon, 30 Mar 2015 10:32:25 GMT - Antoine Martin: attachment set
set to sound-netcompress.patch
allows us to compress raw WAV using the standard packet compressors (only saves about 25% with lz4, probably not worth it)
Thu, 30 Apr 2015 14:36:03 GMT - Antoine Martin: status changed; resolution set
changed from assigned to closed
set to fixed
I think this ticket is good to close, we can deal with testing in #669.
If someone has time, running benchmarks with the netcompress patch could be useful, to see what kind of trade-off we get: 25% compression is poor, but the CPU load is going to be minimal..
Sat, 23 Jan 2021 04:54:19 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/400