#2349 closed enhancement (wontfix)
cache gstreamer config
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 3.0 |
Component: | sound | Version: | 2.5.x |
Keywords: | Cc: |
Description
Related to #2341 and #2347. Similar to #2345.
Instead of running xpra _sound_query
every time we run the client or server, we could cache the results in a text file and just reload it.
We would need to ensure that the timestamp on this file is newer than the gstreamer plugins directory, so that we query it again whenever plugins are added or removed.
This is similar to what gstreamer does with its plugin registry (now found in .cache/gstreamer-1.0/
) - can we re-use this mechanism without incurring the same startup cost?
Attachments (1)
Change History (3)
Changed 20 months ago by
Attachment: | cache-sound-query.patch added |
---|
comment:1 Changed 20 months ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The patch above implements sound query caching, but there are problems:
- complexity
- still takes 100ms because we have to run
gst-inspect-1.0
to ensure that the cache is up-to-date (best case, this can take longer and may break..) - the sound query output includes some pulseaudio things, and those may get updated too - we just don't know when the cache needs to be invalidated
So, I don't think we should be doing this..
comment:2 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2349
Note: See
TracTickets for help on using
tickets.
cache sound query data