Bug 11973 - Un-mute does not work
: Un-mute does not work
Status: RESOLVED DUPLICATE of bug 11217
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: 7.4.0
: PC Windows Vista
: -- normal (vote)
: 7.4.0
Assigned To: Michael Herger
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-05 01:36 UTC by Ian G.
Modified: 2009-06-22 07:55 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments
lightly-tested patch (2.12 KB, patch)
2009-05-07 20:21 UTC, Peter Watkins
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ian G. 2009-05-05 01:36:10 UTC
Similar to bug 11217 but not from CLI - first press of mute works, the display on SB2 shows something like '-800325.79 dB' (am using MusicInfoSCR plugin for alternative volume display), exact number varies. Subsequent presses of mute do not unmute - they show another large negative number and the sound is still muted. To restore volume, the user must increase it as normal.

Same situation with a custom IR map (e.g. muting assigned to 0.hold), or ContextMenu plugin (which gives a mute menu option).

7.4 nightly (currently 26358, also on various nightlies from past week since I first installed).
Comment 1 Peter Watkins 2009-05-07 20:21:27 UTC
Created attachment 5201 [details]
lightly-tested patch

The core problem appears to be that the un-muting code expects to see the volume as a negative number, -1 times the pre-mute volume, but after muting the client volume is always 0, so un-muting restores to -1 * 0 = still muted.

Here's a patch against 7.4 that uses a new pref, preMuteVolume, to allow restoring the volume.

I have NOT tested the behavior with players with synced volumes, though I have attempted to support that.

This has been tested with an SB3 with analog out. With digital volume control enabled, the mixer muting command now works as documented. With digital volume control disabled (volume fixed at 100%), mixer muting now toggles the apparent/displayed/fake volume level, too, and leaves the fixed volume at 100%.

It's not the prettiest patch, but I didn't feel much like trying to rewrite all the hackish underlying "negative volume" stuff.
Comment 2 Peter Watkins 2009-05-08 04:59:53 UTC
Note: that patch probably isn't quite ready. For one thing, the inline comments describing Player::mute() should be updated to reflect what that method now does (I suspect it's basically been replaced with the much more slick fade_volume; all it seems to do now is ensure the permanent volume pref is changed after fade_volume finishes, IIRC). For another, my patch doesn't really optimize mute() but merely makes it work. And the mute code I added to fade_volume() doesn't seem quite clean enough. But at least this code seems to fix the problem.
Comment 3 Ian G. 2009-05-08 05:10:49 UTC
Good news. Is this (or bug patchess in general) built into the nightlies? I am running on Windows, and not able to patch and compile myself.
Comment 4 James Richardson 2009-05-08 05:27:40 UTC
Peter: thank you for the patch

Mark: can you have a look at the attached patch and provide your feed back?
Comment 5 Mark Miksis 2009-05-08 14:30:16 UTC
James, this is definitely not my area of knowledge.  Did you mean to assign it to someone else?  Reassigning to you for now...
Comment 6 Edward Pearson 2009-06-22 00:34:10 UTC
Same as bug #11217 reported 2009-02-27.

Some modules expect mute to be -ve volume others use the mute prefs flag.
See my comment on 11217 https://bugs-archive.lyrion.org/show_bug.cgi?id=11217#c9

Suspect problem introduced when mute implemented as a fade to zero.
Comment 7 James Richardson 2009-06-22 07:55:29 UTC

*** This bug has been marked as a duplicate of bug 11217 ***