linking with forum thread and clearing target for assignment post-review.

I think the "true" device output should be separate from the "displayed" volume such that 3rd party code could alter one without changing the other. This would also benefit owners of gear like the Denon network-enabled receivers that have a TCP/IP CLI for setting and obtaining info.

Architecturally, I'm thinking
 1) have two prefs, "volume" and "displayVolume"
 2) add a new mixer subcommand, displayvolume
 3) all UIs -- web, SqueezePlay, VFD/player -- would display the displayVolume setting rather than the actual device output
 4) volume change mechanisms would continue to call the "mixer volume" command to effect changes, and would offer up/down controls so long as 0 < displayvolume < 100
 5) the "mixer volume" command would by default execute the "mixer displayvolume" command to keep the two prefs in sync so that the displayed volume is accurate

Third-party code could then intercept both "mixer volume" and "mixer displayvolume" commands. A plugin for Denon network gear, for instance, might set the true volume at 100, translate "mixer volume" into Denon commands, and execute "mixer displayvolume" to set the display pref to match the current receiver state.

Third party code interacting with dumb gear -- like IR Blaster with an amp that only receives IR commands -- might be able to approximate the correct displayvolume, and make sure the volume was always > 0 and < 100 so that volume control mechanisms would still offer volume up / volume down options, and still send mixer volume +N/mixer volume -N commands.

I would suggest to run this the other way 'round:
Use "mixer volume" as the volume that is being displayed and add an additional "output volume" that can or can not be linked to the mixer volume.

That way you will not need to change any apps that currently use "mixer volume" since the change would be transparent to them.

I've started fiddling with this. Here's what I'm working towards:
 - adding a new CLI command, 'output' 'volume', that's responsible for changing the player volume and, by extension, updating the "volume" server pref
 - leaving 'mixer' 'volume' pretty much as-is...

...the current official code has 'mixer' 'volume' directly calling a client method that changes the volume on the player, e.g. $client->volume($newvalue). In my approach, 'mixer' 'volume' would execute the CLI 'output' 'volume', and the default implementation of 'output' 'volume' merely calls $client->volume($newvalue). 

Performance looks good. On a Core 2 Duo running around 800 MHz, the new command seems to add about 0.05 to 0.10 milliseconds (yes, milliseconds) to the time required to change the volume. (Actually changing the player volume, with the existing client method, takes 3 times that long, with the SB3 player connected over 802.11g.)

So if you wanted to set the player's real output at 100% and manipulate the volume on the amp via serial or network protocols, you'd write a plugin that "intercepts" 'output' 'volume' (probably with addDispatch). Every time a user requested a volume change with the IR remote, web UI, Controller, third-party app like Moose, etc., those change requests would go to 'mixer' 'volume'. 'mixer' 'volume' would decide what the 0-100 new volume should be, and would ask 'output' 'volume' to make that change. The plugin would prevent the normal client method that changes actual player output from running, and would trigger whatever needs to happen to change the actual amp volume. And the plugin would change the "volume" pref that SqueezeCenter uses for displaying what it thinks is the current player volume -- probably to whatever 'mixer' 'volume' thought it should be. A good plugin would also detect changes made to the amp volume by other means and update the "volume" pref in SqueezeCenter so it remains accurate. For instance, if the Squeezebox player had an IR sensor (as the Classic/SB3 does) and saw an IR code it recognized as an IR command for amp volume, it might query the amp for its volume and update the SC pref. The plugin might also periodically poll the amp to see if the volume had changed some other way -- maybe an IR command the Squeezebox didn't see, maybe someone using the volume knob on the amp itself.

How does that sound to you all?

Something similar might need to be done for the $client->fade_volume() API that's used when muting, but maybe not -- a plugin could intercept 'mixer' 'muting' and handle that on its own.

I see this having utility beyond playing music with a Squeezbox. In my AV system, most of my gear is pretty well hidden. And the Squeezebox volume display is easier to read than the volume display on most amps/receivers -- especially those that have a tiny dot on a big black knob. It'd be nice if I could use my Squeezebox to change the volume while watching a movie or TV with the audio piped through the stereo receiver.

My specific problem has been solved by the xAP plugin.  That plugin sends standard xAP protocol messages on multiple Squeezecenter state changes.  The ones I use are power on off, Volume Up/Down and the absolute value of the mixer volume not the forced 100.

The system that controls my Home theater then receives these messages and deals with the Audio processor over RS232.  It is working perfectly for me.  What is nice is that it does not matter how you change things (remote, web, Transporter panel) the xAP messages always track the player state. 

The use of the xAP plugin with its state messages is a very fast easy way to deal with all sorts of event changes, by player, if you have a PC based control system for controlling audio components.

Hmm, maybe I'm overthinking it. Maybe the solution is as simple as
 - intercept mixer volume and mixer muting
 - for players NOT using the amp volume control, run the real mixer command
 - for players that do use amp volume control, never call $client->volume(), just adjust the amp volume via RS232, TCP, whatever, and set the 'volume' pref for the player so that the VFD, web, and Controller interfaces show the amp's volume
Maybe that's all that the xAP plugin is doing.

I think SC does have to change for this to work well with SC 7.4. I can come close to what I want by doing something like this instead of executing the real mixer volume:

# 1: set the amp volume (has no effect on SC-displayed volume)
&setAmpVolume($newValue,$client); # whatever this takes
# 2: set the client 'volume' pref for SC display purposes
preferences('server')->client($client)->set('volume',$newValue);
# 3: set the temporary volume (not reflected in the SC display)
$client->volume(100,1); # 2nd arg indicates this is a "temporary" change

The problem is that Player.pm registered a pref change handler for the 'volume'  pref, so after step 2, SC changes the actual player volume. pref change handlers cannot be replaced or intercepted, so it looks like there's currently step 2 must result in a brief change in the player's output -- step 3 restores full output quickly, but doesn't prevent the dip. That volume change probably isn't too bad with analog outputs, but for digital it could be a problem, as anything other than full volume messes up things like DTS processing. And even in non-DTS situations, it seems clunky to have a dip/restore every time the volume changes.

If there were a $client->lock_volume() method that would make $client->volume() and $client-fade_volume() do nothing, then a 3rd party plugin could do something like

# at startup, for a $client using the amp's volume control
$client->volume(100);
$client->lock_volume(1); # "1" == lock the output level
preferences('server')->client($client)->set('volume',$ampVolume);

# on volume change requests for a $client using the amp's volume control
# 1: set the amp volume (has no effect on SC-displayed volume)
&setAmpVolume($newValue,$client); # whatever this takes
# 2: set the client 'volume' pref for SC display purposes
preferences('server')->client($client)->set('volume',$newValue);

OK, Barry. I see how xAP is probably working for you. If you're willing to lock the player volume at 100% in the SqueezeCenter audio settings, then you end up with SqueezeCenter reporting a volume level that's a complete fiction. You can even run 'mixer muting 1' and there's no effect on the output level, not even analog (in 7.4). With that setup, it's easy for a 3rd party plugin to intercept 'mixer volume' and handle the amp volume. And no dips in volume level.

Beyond the 100% volume limitation, there's another. If you set two SB3s to synchronize including volume where one has volume fixed at 100% and the other allows volume changes, changes to the fictional/amp volume player don't have any effect on the player that allows changes (but changes on the player that does allow true volume control do affect the fictional volume on the other player). I suppose I should look for/open a bug on that.

My personal issue was only with my Transporter in my Theater.  that is the only one I use to play DTS encoded music.  When playing DTS encoded music the volume must be fixed at 100%

Barry, do you still care about this, or should it be closed? Personally I'm taking advantage of the fixed output + fictional volume with my Denon amp, and am quite happy with the behavior in 7.3 and 7.4.

As far as I am concerned it may be closed.

Closing per comment 11