[gstreamer-bugs] [Bug 528060] Removing a mixer device does not remove it from gnome-sound-properties

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Wed Apr 16 12:44:24 PDT 2008


If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=528060

  GStreamer | gst-plugins-base | Ver: 0.10.x

Tim-Philipp Müller changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t.i.m at zen.co.uk
             Status|UNCONFIRMED                 |NEEDINFO




------- Comment #4 from Tim-Philipp Müller  2008-04-16 19:44 UTC -------
I see the problem, but I'm not really sure if this falls into GStreamer's
domain. I don't see us implementing what would basically amount to a hal-light,
so the only thing we could do is poll regularly for changes.

Anyway, I can think of at least two other possible solutions to this:

 (a) when you get the mixers via gst_audio_default_registry_mixer_filter(),
     they are in READY state. I presume you set the mixers not currently
     selected back to NULL state, otherwise the rmmod would probably fail.
     So what you could now is just set up a timer which tries to set all
     mixers (or only the unselected ones?) to READY state and back to NULL
     every few seconds. If you can't set a mixer to ready state, the device
     has probably disappeared and you can remove it from the list or
     re-build the device list. That doesn't get you any new devices added
     to the system of course.

 (b) there's a hal plugin in gst-plugins-good (halaudiosink etc.). You could
     add a haldevicemonitor element or so which your application could create.
     When set to READY state the element could create a watcher thread with
     a main context + main loop and watch for changes in audio devices, and
     post element messages on the bus, which the application could intercept.

Any better ideas?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=528060.




More information about the Gstreamer-bugs mailing list