#400 closed enhancement (fixed)
sound improvements - better queue handling, refactoring and cleanups
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | minor | Milestone: | 0.15 |
Component: | sound | Version: | |
Keywords: | Cc: |
Description (last modified by )
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:
Attachments (2)
Change History (20)
comment:1 Changed 8 years ago by
Milestone: | 0.11 → 0.12 |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | new → assigned |
comment:2 Changed 7 years ago by
Milestone: | 0.12 → 0.13 |
---|
This is needed, but needs to be done early in the release cycle to find all the problems. Re-scheduling.
comment:3 Changed 7 years ago by
Milestone: | 0.13 → 0.14 |
---|---|
Priority: | major → minor |
comment:4 Changed 7 years ago by
Description: | modified (diff) |
---|
comment:5 Changed 7 years ago by
comment:6 Changed 7 years ago by
Description: | modified (diff) |
---|
comment:8 Changed 7 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
r7757 fixes this sink warning found on OSX:
pipeline warning: ['gstbasesink.c(3638): gst_base_sink_chain_unlocked (): \ /GstPipeline:pipeline1/GstOsxAudioSink:osxaudiosink1:\n\ Received buffer without a new-segment. Assuming timestamps start from 0.']
afarr: please check that I haven't broken anything on win32 or osx.
comment:9 Changed 7 years ago by
Description: | modified (diff) |
---|
comment:10 Changed 7 years ago by
Owner: | changed from alas to Antoine Martin |
---|
Sound still seems good, both OSX and Windows. SInk warning also gone.
Probably good to close this.
comment:11 Changed 7 years ago by
Status: | new → assigned |
---|
I'm not closing this ticket yet because there are still quite a few items that I haven't dealt with.
comment:13 Changed 6 years ago by
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.
Changed 6 years ago by
Attachment: | sound-underrun.patch added |
---|
deal with underruns better: try to use min-threshold-time
comment:14 Changed 6 years ago by
comment:15 Changed 6 years ago by
r8827 allows us to disable this new variable min queue code using:
XPRA_VARIABLE_MIN_QUEUE=0 xpra attach ...
Changed 6 years ago by
Attachment: | sound-netcompress.patch added |
---|
allows us to compress raw WAV using the standard packet compressors (only saves about 25% with lz4, probably not worth it)
comment:17 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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..
comment:18 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/400
some minor improvements were made for 0.11, the rest should get done for 0.12