GNOME Bugzilla – Bug 672401
[pulsesink] mute property can't be unset
Last modified: 2012-04-24 14:30:55 UTC
gst-launch-0.10 playbin2 uri=file:///path/to/favorite/music # Music plays ... gst-launch-0.10 playbin2 uri=file:///path/to/favorite/music mute=TRUE # Music plays but is muted as expected gst-launch-0.10 playbin2 uri=file:///path/to/favorite/music # Music is still muted, despite mute property default value supposed to being FALSE gst-launch-0.10 playbin2 uri=file:///path/to/favorite/music mute=FALSE # Music STILL muted Can only get it unmuted when letting it play and then workarounding it by changing the mute for the per-application volume in PA enabled gnome sound settings or pavucontrol. alsasink is only muted in the above command sequence when mute=TRUE is explicitly given (including when going through PA alsa-plugins hook to PA). It feels like volume property is similarly wonky.
commit e7240413a7b678cc89c0b68cf15d68c7f14d921a Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Apr 24 15:34:57 2012 +0200 pulsesink: start unmuted when requested When we explicitely set the mute property to FALSE, connect to pulseaudio with the PA_STREAM_START_UNMUTED flag set, otherwise pulseaudio will use its previously used value (which might start the stream muted). Fixes https://bugzilla.gnome.org/show_bug.cgi?id=672401
I believe above patch fixes things. The idea with the volume (and now also the mute) property is that when you don't explicitly configure them, pulseaudio chooses good values for you. This usually means restoring the previous volume/mute but you can ask pulseaudio to not do that. If you (from GStreamer side) explicitly set the volume/mute, it overrides anything pulseaudio would do and uses those values instead. This means that the default values of the GObject properties don't reflect what the real values will be. It would be nice if we had a default for them that said 'automatic' or so.