Is this about not updating ion the fly, or after closing and reopening the dialog?

Sorry, I should have stated: this is on-the-fly. After restarting the program, the mixer list is updated.

I don't see any way to get notified by GStreamer about a mixer going away, currently.

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?

Forgot the brute-force approach:

 (c) add some kind of gst_audio_default_registry_mixer_hash() which you
     could call regularly from a timer and which returns some kind of hash,
     so when the list of available elements/devices that would be returned
     by gst_audio_default_registry_mixer_filter() changes, the hash changes
     and your app could re-build the list.

> 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.

Which makes me wonder. Device additions are actually already handled using HAL (I'm not sure we really need (or want) to support automatic device updates in non-HAL-enabled builds). Device removals, too (e.g. USB audio devices). Does this mean what we see is in effect a bug/missing feature in HAL because it should detect module unloading just as well?

> Which makes me wonder. Device additions are actually already handled using HAL

I only glanced at the code, but it seems to me that this is only true for ALSA devices.

(On a side note, this is all a bit awkward. IMO the hal->alsa device mapping code should really live in halaudiosink and then be queried via the GstProperty interfaces, or ideally some kind of new GstDeviceProbe interface which makes all the interesting information like the device, the name/description etc. available in one swoop)

> Does this mean what we see is in effect a bug/missing feature in HAL because
> it should detect module unloading just as well?

I don't know if hal covers oss devices, but if it does you're ignoring them from the looks of it.

> I only glanced at the code, but it seems to me that this is only true for ALSA
> devices.

For additions, true. But assuming HAL supported OSS, removals should work afaics.

> (On a side note, this is all a bit awkward. IMO the hal->alsa device mapping
> code should really live in halaudiosink and then be queried via the GstProperty
> interfaces, or ideally some kind of new GstDeviceProbe interface which makes
> all the interesting information like the device, the name/description etc.
> available in one swoop)

I'm not sure what that would mean, exactly (what with all the gstreamer jargon), but I'm certainly not going to argue that having to query HAL directly feels a bit tacked on.

> I don't know if hal covers oss devices, but if it does you're ignoring them
> from the looks of it.

Sam, do you know whether HAL is supposed to support OSS?

Answering myself, from the spec it looks like it does. I'll try to cook up a patch.

Tim, do you want to keep this as a reminder for the halaudiosink enhancements? Otherwise feel free to push back to control-center.

I get the feeling that the HAL properties for OSS don't provide a way to make the distinction between input and output devices that would be required for g-s-p...

Is this still a problem nowadays? hal is deprecated, GNOME uses pulseaudio by default, ...

Assuming this to be OBSOLETE. Please reopen if that's not the case.