An incremental volume change request when a player is muted should 'unmute' before applying the change

[SamInPgh]

Currently, an incremental volume change when the volume is muted (negative value) sets the player volume to its minimum value (usually 0) before applying the incremental change. It should instead unmute (multiply the value by -1) prior to applying the volume change, which is the behavior that would be expected based on how AV receivers operate. Muting is not the same as setting the volume to 0. As more client apps begin supporting the player 'mute' function, this change becomes more important.

[mherger]

I'm open for a discussion of this topic (might see more activity if lead on forums.slimdevices.com).

But I personally would not agree: if I mute, I'd use unmute to go back to where I was. I would not see when I would want to increment the volume from a muted state, except if I didn't know it was muted. Because incrementing volume from not hearing nothing to x+1 doesn't make sense if you don't have x as the reference. Therefore it's IMHO correct to start at 0. If you want to go back to the volume where you muted, just unmute instead.

[philippe44]

I corrected an issue in volume a couple of days ago and I took the opportunity to look at this. It's located in S::C::Command.pm @ line 672

if ($newvalue =~ /^[\+\-]/) {
			$newval = $oldval + $newvalue;
		} else {
			$newval = $newvalue;
		}

@SamInPgh, if you want what you have to check that $entity is volume and then if $oldval is < 0 (muted), apply the unmute code or do a more complete check on line 616 to see if this $entity is volume and current volume is < 0, then you'd do an unmute, as if $entity was muting = 0.

Now, regarding the best option for UX, I really don't have an opinion, I see it as a matter of personal preference because I can see the case where you want to lower the volume while being muted so that when you unmute, it's not as loud. You see, a 3rd option that would be my preferred 😄

[SamInPgh]

Thanks for the feedback, @philippe44. Imho, the crux of the matter is the fact that every A/V receiver I have ever seen or heard of treats a mute command differently than setting the volume to 0. Obviously an unmute results in a return to the volume prior to the mute. But a volume change (volume up/down) also results in an unmute followed by application of the incremental change. For instance, if the volume is at 45, it remains at 45 (or, in our case, -45) during the mute and an unmute resumes it at 45. By the same token, hitting the "volume down" key on the AVR remote would first unmute and then decrease the volume by the amount requested -- say to 42, not to -3 (or 0 in our case). I challenge you to find any AVR that doesn't behave in the way I describe. Regarding the code change needed to remedy this issue, I believe that the key lies in the few lines just before the ones you listed, starting at line 665. I'm including the comment lines because they actually support my position:

	# if the player is muted and the volume changed, unmute first
	# we're resetting the volume to 0 to mimick the IR behaviour in case of relative changes
	if ($entity eq 'volume' && $prefs->client($client)->get('mute')) {
		$prefs->client($client)->set('mute', 0);
		$oldval = 0;
	}

The comment lines state the intent to 'unmute first' and 'to mimick the IR behaviour in case of relative changes'. However, 'resetting the volume to 0' is neither an unmute nor a mimicking of IR behavior (see above). As I said above, muting is not the same as setting the volume to 0. It follows, then, that an incremental volume change while muted should not be treated the same as an incremental volume change while the volume is set to 0. While I may not have a full grasp of the client code here, I believe that the change should be as simple as replacing one line, looking something like the following:

	if ($entity eq 'volume' && $prefs->client($client)->get('mute')) {
		$prefs->client($client)->set('mute', 0);
		$oldval = abs($oldval);     # safer than multiplying by -1
	}

Again, maybe my 50 years of experience as an audio 'enthusiast' (a level below audiophile) has distorted my perception of what is 'intuitive' when it comes to this issue but, regardless of that, I feel strongly that the change I propose makes infinitely more sense than the present behavior.

I am tempted here to say "I rest my case". However, I am prepared to argue the issue further if necessary. ;-)

Thanks for your attention.

[aesculus]

I favor the fix @SamInPgh if it's workable. I don't like the volume to go to 0 when mute is just a state in amplifiers of no output.

BTW if my amp is in Mute mode and I make any volume change with it's remote, it immediately comes out of Mute mode.

[SamInPgh]

In order to address concerns raised by @mherger with regard to changing long-standing behavior that some users may rely on, I propose adding an option like "Volume setting on un-mute" to the LMS Player->Audio menu that would default to a value of 0 but could be set to any integer from 0-99 as well as to "Volume before mute", which would set the variable to -1 and trigger the behavior that I favor. While I'm not familiar with the effort required to add the menu option, the code changes to make use of it would be minimal.

[michaelherger]

I knew this request would come... I hate the idea of adding yet another parameter to cover yet another corner case. Now if you came up with a PR, I could consider merging it. But I personally prefer to spend my time on more important changes. Thanks for your understanding!

[SamInPgh]

No problem, Michael. I already coded and tested my inelegant kludgy workaround and it's working exactly the way I want it to now. If the LMS code was changed, I would just have to go update it again. So let's just let it go. Thanks for listening, and thanks for all you have done and continue to do for the Squeezebox community.

-Sam

[SamInPgh]

Should I consider this discussion dead now? If there is no hope for even an optional menu-selectable change to the current behavior with regard to this issue, I will go ahead and deal with it in the plugin by saving the previous volume and restoring it to both the AVR and the LMS player after an unmute event, which is an inelegant and kludgy solution. There are times, however, when a kludge is the only option.

[philippe44]

AFAIK, @mherger is away for now, so let's give him some time 😄

[SamInPgh]

Alright. Sorry. I can get a little impatient sometimes. Okay, most times. 😏