GNOME Bugzilla – Bug 755106
directsoundsink: mute property doesn't work
Last modified: 2016-04-18 06:48:54 UTC
Muting the audiosink with g_object_set(directsoundsink, "mute", true, NULL); has no effect here. Testing with gst-launch-1.0.exe audiotestsrc ! directsoundsink mute=1 shows the same effect.
Created attachment 317359 [details] [review] set mute value at startup an fix correct set and get mute function - set mute value at startup - correct set and get mute function
commit fb5a5c069ce32b8d0915251f9e3cc8000a23d8ec Author: Thomas Roos <thomas.roos@industronic.de> Date: Mon Dec 14 14:15:00 2015 +0100 directsoundsink: Fix handling of the mute property - set mute value at startup - correct set and get mute functions https://bugzilla.gnome.org/show_bug.cgi?id=755106
Could it be the cause why volume is no longer applied correctly in recent releases? - Setting the volume to 50%, then muting/unmuting, volume is reported as 50% but is actually 100% (it's loud) - Setting the volume to 50%, recreate the element, volume is reported as 50% but is actually 100%.
- please check your version, it should be fixed first in version: 1.7.90 - what do you mean by recreate the element?
This also made it into 1.6.3. By recreating I mean I create a new directaudiosink for each now stream. But, I currently can't build GStreamer on Windows, so feel free to ignore this. I've reverted to 1.4.5 for now.
Christoph, can you report a new bug about this with a testcase? Also please check if this is the exact change that breaks it, or if any of the others.
Found bug when unmuting - the wrong volume value is used. Patch attached, about the second "recreate" I don't know what exactly you're doing - maybe a minimal example program wouldbe useful.
Created attachment 323391 [details] [review] fix volume reset on unmute
I'll try to come up with an example.. Two other issue I see with the original patch: * Muting and then setting the volume will unmute (There should be a check for mute in set_volume()) * The debug message in set_volume() prints the stored volume not the applied one.
* I don't completly agree - I think it's ok to autounmute, but you are right mute flag should also be unset automatically? Do you agree? * debug message - I agree - but don't know the original intention
> Do you agree? I think it would be better it had the same behavior as the volume element and other audio sinks, which handle mute and volume separately.
Yes, mute and volume should be completely separate. Can you update your patch accordingly?
No, I think the problem is a bit deeper - in this plugin volume and mute is pretty much the same - it all set the stream volume. Usually a mute is a mixer switch which disable a channel. So I'm unsure if a mute is useful at all. I did not introduce the mute. I just fixed that the parameter mute is passed to the plugin from command line (the original bug). I don't use the mute and I dont need it - so I would suggest Christoph should do it the "correct" way ;) P.S: attachment 323391 [details] [review] is still correct and has nothing to do with this bug or my earlier patch
You would just remember the mute and volume settings separately, and whenever mute=true you would set the directsound volume to 0. And whenever mute=false you would set the directsound volume to the value of the volume property.
Created attachment 323417 [details] [review] setting volume does not unmute patch 317359 and 323391 are required as well
commit 93d09f0474567c06efef3c77fb0e034a5d4a2f63 Author: Thomas Roos <thomas.roos@industronic.de> Date: Tue Mar 8 17:37:17 2016 +0100 dirctsoundsink: Setting volume should not unmute https://bugzilla.gnome.org/show_bug.cgi?id=755106 commit e345a7fee9dc0190b59a49967818ae88dc71fe8c Author: Thomas Roos <thomas.roos@industronic.de> Date: Tue Mar 8 13:57:24 2016 +0100 dirctsoundsink: Fix volume reset on unmute https://bugzilla.gnome.org/show_bug.cgi?id=755106
Installed 1.6.4 and now I can mute, but I can't unmute with g_object_set(directsoundsink, "mute", <true|false>, NULL)? Have to change the volume to get sound again.
*** Bug 731149 has been marked as a duplicate of this bug. ***
Thomas, can you open a new bug about this with the exact course of events that you're trying?