Tom: is this one yours, or Ben's to look at implementing?

"Output level is fixed at 100%" is no longer an option (related to bug 14257?), but Touch should have this option.

As with SB Classic, "Output level is fixed at 100%" should mean that 
 - digital and analog outs are fixed at the equivalent of volume level 100
 - Touch should still have a "volume" preference, but that volume should be a total fiction

This would allow plugins like my DenonSerial (http://www.tux.org/~peterw/slim/DenonSerial.html) to change the amplifier volume to match the fictional Touch volume, and let the display on Touch, Controller, etc. reflect the current amplifier volume.

I think this would be Ben's to look at in the new world order, but of course not as high priority as many of the alarm bugs.

Changing priorities due to management guidance.

This one will be critical for me I have pre-ordered a touch.

But I'll be using the digital output, thus want to hav fixed volume.

And have a bunch of DTS and dolby tracks.
These will be very loud white noise if the volume is anything but 100% so frying speakers is obviously an option.

Post SB Touch release I'll be working with Felix to get this and bug 15826 in a.s.a.p.

People please vote for this bug to get put back on our priority list

Also, while you're voting help us put some thought into how the UI should look.  IIRC the older IP3K players still let you adjust the volume, and the on-screen volume slider moves, but there is no change in the actual volume level.

This *does* cause some user confusion when someone ticks that checkbox without really understanding what it means!

As I noted in comment #2, for some use cases it is not only valuable but very important that there be a "fictional" volume display that can be manipulated. That's the only way that users of plugins like my DenonSerial and Aesculus' Denon AVP Control can control amplifier volume via different user interfaces (IR, Controller, Web, iPeng, etc.).

With the applet framework in SqueezePlay, even players connected directly to MySqueezebox.com could make use of a fictional volume -- for instance, a DenonSerial Lua applet running on an SB Touch could use a $10 serial adapter to control external amp volume without regard to what the Music Source is. So this need for fictional volume should not be seen as limited to SBS+plugin setups.

I can appreciate the potential for confusion, and would welcome a 3-state choice for players (volume is adjustable, volume is fixed and always appears as 100%, volume is fixed at 100% but apparent/displayed volume level can be altered). This would take more work, though, and those of us who need fictional volume levels need it each and every day, while those confused by the fictional volume display should learn to adapt quickly. So I think it is more important to provide the fictional volume level than to address confusion felt by some users.

To heap more work on Ben (and maybe Michael and Andy, too), it might be nice in a 3-state model if the UI didn't display any kind of volume level if the user chose "volume is fixed and always appears as 100%". As I understand it, iPeng already does that -- see this long thread in which a few of us 3rd-party developers standardized on a new CLI command (getexternalvolumeinfo) to help UIs like iPeng distinguish between "fixed at 100% and don't show volume" and "fixed at 100% but *do* offer to change the volume, as 3rd-party software controls the amp volume"): http://forums.slimdevices.com/showthread.php?t=74458

Thanks.

Would simply making the digital outputs fixed, like most AV equipment, solve this problem for most users?

It should work the same as it does with SB2/3 and Transporter.

(In reply to comment #7)
> People please vote for this bug to get put back on our priority list

22 votes now Chris.  That puts it in the top 1/4 of 1% of all bugs.

Yes basically it should works as it does in an SB3 an UI setting to fix the volume.

To rally more votes , as being in the top 1% percentile is not enough

I started this tread.

http://forums.slimdevices.com/showthread.php?t=77288

lets see if we get anymore votes

I just got my Touch that replaced a SB3 and it is a total disappointment that I cannot use the Touch to play my substantial collection of DTS and AC3 surround sound music on my newest device.

You can just keep volume at 100% in the Touch hide the remote from family and friends so they don't adjust it while you playing those files.

I have a problem with desktop SqueezePlay where the volume knob on my keyboard adjusts my computer's volume at the same time it adjusts the volume in SqueezePlay.

I think that forcing SqueezePlay to have a fixed, 100% volume would correct this problem.

Adding my vote.

For those who want or need volume fixed at 100%, I have posted instructions on how to achieve that on the forums: http://forums.slimdevices.com/showthread.php?t=77837

I hope to release a proper patch for use with Erland's Patch Installer applet so this will be easier to install (and re-install after firmware updates), but at least this should help some of you who need 100% right now.

Also, Chris, regarding comment 10, I posted a poll about your suggestion on the forums yesterday.
http://forums.slimdevices.com/showthread.php?t=77824
What I take from that poll is that 1) a fair number of forum readers, like voters for this bug, want the option to fix the volume at 100% *and* 2) a fair number (over 50%) want variable digital output -- so always fixing the digital outputs at 100% is likely not a good option.

44 votes now. Only 5 unresolved bugs have more votes than this one.

pst Peter don't tell them ;) now that there is a known workaround, they will down prioritize this further.
If you also do a patch it will slide even further (then anyone can install) ;)

+1

Really need to add the "fix volume at 100%" option. Especially for those of us using the Touch as a digital transport

I am using small digital amplifier from www.sumoh.com

This has digital input only so I really need the adjustable volume in digital output

Best Regards,
Jonas

(In reply to comment #20)
> I am using small digital amplifier from www.sumoh.com
> This has digital input only so I really need the adjustable volume in digital
> output
> Best Regards,
> Jonas

It would be an option you can enable/disable.

 == Auto-comment from SVN commit #31191 to the slim repo by bklaas ==
 == http://svn.slimdevices.com/slim?view=revision&revision=31191 ==

Bug: 14807
Description: add menu item Settings->Audio->Fixed Volume to players with digital out capability
send playerpref for digitalVolumeControl in playerstatus message
trigger playerstatus notification when playerpref for digitalVolumeControl is set/unset

Squeezeplay-side checkin is also coming for this

 == Auto-comment from SVN commit #9037 to the jive repo by bklaas ==
 == http://svn.slimdevices.com/jive?view=revision&revision=9037 ==

Bug: 14807
Description: support for obeying server-side playerpref for fixed 100% volume output
UI and skin support in Now Playing for fixed volume
add player object method getDigitalVolumeControl() to query setting
IRBlaster support is not (fully) there yet, will be working with Felix on this

I'd invite any beta testers running 7.6 on both SBS and on their SB Touch to give this a shot with the next nightly build of server and player firmware.

After upgrading, look for Settings->Audio Settings->Fixed Volume

The feature may have some blemishes out of the gate, but we'll get there.

 == Auto-comment from SVN commit #31195 to the slim repo by bklaas ==
 == http://svn.slimdevices.com/slim?view=revision&revision=31195 ==

Bug: 14807
Description: add missing strings

 == Auto-comment from SVN commit #9039 to the jive repo by bklaas ==
 == http://svn.slimdevices.com/jive?view=revision&revision=9039 ==

Bug: 14807
Description: fix small but significant typo that caused volume adjustment to fail

I've played with this a bit, so far just using the analog outputs.  Touch and IR volume adjustment are completely disabled when fixed volume is enabled (see below).  The web interface of SbS 7.6 still causes the volume to change.  What I see on the Touch's display when this happens is that the volume slider still shows 100%.

From Peter's comments above (and the behavior on prior Squeezeboxes) the expected behavior is to be able to change the volume *numbers*, but that doing so would have no effect on the actual volume.  This should be reflected in the web and device interfaces, so that the touch slider can still be used and the volume buttons on the remote should bring up the volume control overlay.

I also tried it now

Now Touch honors the fixed 100% volume setting from it's front display ir-remote or controller.

But one bug remains it still responds to volume changes from the web-UI

Version: 7.6.0 - r31209 @ Sun Aug 15 03:01:55 MDT 2010

(In reply to comment #28)
> I also tried it now
> 
> Now Touch honors the fixed 100% volume setting from it's front display
> ir-remote or controller.
> 
> But one bug remains it still responds to volume changes from the web-UI
> 
> Version: 7.6.0 - r31209 @ Sun Aug 15 03:01:55 MDT 2010

Behaviour in web-UI confirmed in 7.6.0 - r31401

Created attachment 7052 [details]
ignore web UI (or any server-driven) volume changes

this patch will probably deal with the web UI volume change issue when 100% fixed is set. Will require some further testing before approval in 7.6.

this is a 7.6.0 target bug.

fwiw, this is by far the #1 bug on my plate for inclusion with a 7.6.0 release

What about player side?  And bug 15826.  Are the controls still locked, or can they also be allowed to adjust the volume setting but be ignored?

Ok is the patch tested enough yet ? it would be nice to have this fixed.

So all server driven volume changes are ignored,Web-UI crodsfade and replay gain

Nope the patch does not block crossfade :-/
supose it don't block replay gain either ?

But it blocked the web-UI .

But it's still no fixed volume

Ben
your change will prevent that the players volume is ever set to 100%

So people who have the volume at 50% and then turn off digitalvolumecontrol will stay at 50% now.
Not good.

You should rather call 
decode:audioGain(65536, 65536)

 == Auto-comment from SVN commit #9303 to the jive repo by bklaas ==
 == http://svn.slimdevices.com/jive?view=revision&revision=9303 ==

Bug: 14807
Description: in _audg, set audioGain to 65536 on both channels when 100% fixed volume is set for the player
Simplify setting the slider on NP screen with a _setVolumeSliderStyle() method
Fix UI bug on NP screen when switching control between different players with different volume settings

For those following this bug, please let me know if the last checkin (will be in the next beta firmware tomorrow) works well for you.

Apologies Mikael, but the last few comments regarding crossfade and replay gain don't make sense to me. Could you explain clearer what problem you are experiencing?

It's like this even if you have.

decode:audioGain(65536, 65536)

Replay gain tags is still going to lover the volume, they go via some c code somewhere i think ?

But you can turn that off separately I know that ? but how many users are aware of this and there rg tags some user weird reports on the forum makes you wonder.

According to Andy the changes I made to jive.audio.Playback._audg() should be okay with regards to crossfade and replay gain. Alan is going to review as well.

We're working through some issues with our build server so the 7.6 SB Touch build with these changes is delayed. Hope to have it resolved today so people can give this a test drive.

(In reply to comment #38)
> It's like this even if you have.
> decode:audioGain(65536, 65536)
> Replay gain tags is still going to lover the volume, they go via some c code
> somewhere i think ?
> But you can turn that off separately I know that ? but how many users are aware
> of this and there rg tags some user weird reports on the forum makes you
> wonder.

PLEASE DO NOT connect/conflate "fix volume at 100%" with replaygain and crossfade - they are totally different things and I need fixed DIGITAL volume + the ability turn rg and CF ON/OFF in the web UI!

On a different note, what is this fix going to do to Soundcheck's "ttvol100 mod" ? I already believe this code hack to be 100% redundant with the proposed code change to fix this bug... could someone please confirm this?

This is the GREP hack in question:

REV=Beta.X.1
TYPE="volume 100%"
STRING1="decode:audioGain(data.gainL, data.gainR)"
STRING2="decode:audioGain(65536, 65536)"
FILE1="/usr/share/jive/jive/audio/Playback.lua"

header () {
echo "________________________________________________________________"
echo
echo "soundcheck's SB Touch Toolbox $REV: The $TYPE mod!"
echo "________________________________________________________________"
echo
}

footer () {
echo "________________________________________________________________"
echo
}



#####main################################

test -f /etc/init.d/rcS.local || { echo "Touch toolbox has NOT been initialised! Please run ttinit first" ; exit 1 ; } ;

test -f $FILE1 || echo "$TYPE no data file found "
test -f $FILE1.orig || cp $FILE1 $FILE1.orig


if [ "$( grep "$STRING2" $FILE1 )" = "" ] ; then  
      sed -i "s/$STRING1/$STRING2/g" $FILE1
      STAT=enabled
else
      sed -i "s/$STRING2/$STRING1/g" $FILE1
      STAT=disabled 
fi

header
echo "Modifcation $TYPE  $STAT. Rebooting system."
footer
sleep 3
reboot


exit 0

Provided you set the SB Touch to 100% fixed volume via Settings->Audio->Fixed Volume, it's redundant to that sed hack of the file.

Ben - please see my earlier comment - does "OK with..." mean that RG and crossfade are still applied correctly when vol is fixed?
thanks
Phil

Q: does "OK with..." mean that RG and crossfade are still applied correctly when vol is fixed?

A: yes

But it needs testing.

(In reply to comment #43)
> Q: does "OK with..." mean that RG and crossfade are still applied correctly
> when vol is fixed?
> A: yes
> But it needs testing.

Great - will test ASAP!
thanks
Phil

(In reply to comment #42)
> Ben - please see my earlier comment - does "OK with..." mean that RG and
> crossfade are still applied correctly when vol is fixed?

What do you mean 'applied correctly'?  They should have no effect on actual volume when volume is fixed at 100%. Correct?

"Applied correctly" IMO should mean that replaygain (track, album, or smartgain) and crossfade are always applied *if enabled by the user*, even if volume is "fixed" at 100%.

I have a wide range or replaygain values in my library, as my collection includes some conservative rips of LPs whose replaygain is around +10 dB. Replaygain allows me to play mixes that include those "quiet" LP rips and "loud" new CD rips that have negative replaygain without adjusting any volume control.

Volume fixed at 100% allows me to switch between the Squeezebox and other amp sources without worrying about volume levels, and use my Squeezebox to see and change the amp volume.

Please don't force me to choose between locked output and replaygain -- I want to use both. If you don't want RG or crossfade affecting your output, just turn RG & crossfade off for your Squeezebox.

Crossfade and Replay Gain are intended to be functional features, including when 100% fixed volume is set.

r9306 is built and published to the update servers. Let me know how you get along with this one. I'm expecting to iterate on finer details before this bug can be considered fixed.

Six of one, half dozen of the other.  I would think that if you wanted to use crossfade and ReplayGain then almost by definition you're not interested in fixing output at 100%.

How does fixed output work with ip3k players in regard to crossfade and RG?

(In reply to comment #48)
> How does fixed output work with ip3k players in regard to crossfade and RG?
I can't really tell about RG because I've never used it (none of my files even has a RG tag embedded), but I'm using both the "smart" cross-fading feature and the 100% fixed volume feature (because I use my amp to adjust volume) with my Transporter.

So, I guess it already works on IP3K the way Ben has just implemented it on SqueezePlay.

You shouldn't see "100% fixed volume" as an audiophile oriented feature, it's much more of a handy feature for people who want to control volume from another source than the Squeezebox.
As Peter said, if you can't stand RG and cross-fading, you're still free to disable them.

Ok I understands the arguments cool lets have rg and fade still active , but document that it is so in the help text in the UI .

My intended usage of fixed volume is as a "bitperfect transport" button, so that I can make sure that no signal manipulation is going on with one setting . I can live with using 3 settings to accomplish thisI only have to set it once for only 1 of my players , the rest should have volume.

Looks like the touch interface isn't quite hooked into this yet.  Unlike the web interface, the slider doesn't indicate the volume level and can't be used to adjust it.  The left 'speaker' button decreases the volume level by one (should be three, IIRC) and only the first time that it's used.  The right speaker button always jumps the volume level to 100%.

The intended behavior of the Touch UI when it's pointed to a player (typically, but not necessarily, itself) that is set for 100% fixed volume:

a. Slider shows a "disabled and full" treatment-- the "pill" that can be used to adjust volume should be gone, and the slider should be filled with white.

b. Vol up and Vol down buttons should do nothing to the SB Touch's volume.

Can anyone else confirm what Zolx is seeing?

Please also note that the intention is not to mimic the Web UI's behavior. If anything, I believe our treatment in the Web UI is (dead) wrong, and should also indicate volume that's not settable. That's what we've been doing for ip3k players for years though, and that's beyond the scope of what I'll fix for this particular bug.

If you have 100% fixed volume set on the Touch, it should not be possible via the SB Touch to change the volume. Automatic vol adjustment for Crossfade and Replay gain behavior is observed, though neither of these is enabled by default. My tests thus far have shown this to be the case, so I'm very interested to know if others are not seeing this.

What about bug 15826?  Also, Peter's comment #2 and comment #17:

"Volume fixed at 100% allows me to switch between the Squeezebox and other amp
sources without worrying about volume levels, and use my Squeezebox to see and
change the amp volume"

I thought the ability to control the volume of an external amp was much of the reason for implementing this and how it's always worked with ip3k players. It's not just about mimicking the web interface.

I solicited feedback from Felix on this to make sure I wasn't shooting IR Blaster in the foot with the Touch UI for this bug:

"There is a difference between changing local volume (or not) vs. amp volume (via IR Blaster). I think the current implementation on SB Touch is what it should be: Volume at 100 all the time (with exceptions rg and crossfade)."

(In reply to comment #52)
> The intended behavior of the Touch UI when it's pointed to a player (typically,
> but not necessarily, itself) that is set for 100% fixed volume:
> 
> a. Slider shows a "disabled and full" treatment-- the "pill" that can be used
> to adjust volume should be gone, and the slider should be filled with white.
> 
> b. Vol up and Vol down buttons should do nothing to the SB Touch's volume.
> 
> Can anyone else confirm what Zolx is seeing?

Just to clarify... 

I am seeing the visual treatment described in 'a'.

For 'b', what I'm seeing can be verified in the web interface by examining the volume (you can mouseover the volume bar) after changing it on the Touch.  

A more accurate description of what the buttons do: The volume down button always  readjusts the numeric volume level (not the actual Touch volume) to 99% and works exactly once until the volume level is adjusted again.  The volume up button always readjusts the volume level back to 100%.  So if you adjust the volume level to, say, 60% in the web interface it will jump to either 99% or 100%.

The behavior using the IR remote is identical.

(In reply to comment #54)
> I solicited feedback from Felix on this to make sure I wasn't shooting IR
> Blaster in the foot with the Touch UI for this bug:
> 
> "There is a difference between changing local volume (or not) vs. amp volume
> (via IR Blaster). I think the current implementation on SB Touch is what it
> should be: Volume at 100 all the time (with exceptions rg and crossfade)."

Maybe I don't understand how IR blaster works.  I'll defer to Peter.  I thought that the controls must be able to change the volume level (not the local volume) so that the new volume level can be relayed through IR blaster.

IR Blaster offers a "write-only" interface that can send commands  like "volume up" and "volume down" to an amp that supports IR remotes. I've used it in the past, and been grateful for it. No offense to Felix, but IR Blaster is "dumb" and primitive (it's not Felix's fault, it's a limitation of IR control protocols in general, and vendor choices***). 

Please don't aim for *just* making IR Blaster work with Touch. Aim higher. The good news is that all you need to do is keep doing what IP3K has done for years -- maintain a fictional volume when the output is locked at 100%. 

Many amps offer RS232 or TCP/IP interfaces for control. Many of these, including Denon's, offer not just "volume up" and "volume down" commands, but the ability to set an exact volume level in one command. Send "MV60" + carriage return to a Denon amp's serial port or TCP port 23 and it will change the master volume to -20 dB (MV80 = 0 dB) immediately. For such amps, the IP3K fictional volume model is great. I can use my Controller or the web UI or a SB3 IR remote to set an exact fictional volume and my DenonSerial plugin will set an exact volume level on my amp. I use this every single day. In theory, with amps like this you could even rely on your Alarm Volume being respected, as the plugin could ensure the amp was turned to the appropriate level.** IR Blaster can't do that.***

Many amps with RS232 or TCP/IP control interfaces also allow querying the amp for status information. My plugin periodically polls the amp to check its volume. So if somebody adjusts the volume via the Denon's front panel knob, Squeezebox Server sees that and *all* the Squeezebox interfaces reflect the new volume. 

It seems to me that
 1) "Fixing" the volume control in the touchscreen UI while leaving the "dead wrong" behavior in the web UI is not a good result. If there has been significant negative feedback or customer service costs related to IP3K's fictional volume when its output level is locked at 100%, as Chris seemed to suggest in comment 8, and you don't want to offer a 3-state choice (comment 9) then fixing all UIs should be in scope.
 2) Locking the volume control is a case of focusing your UX on 1980s control technology (IR codes) in such a way as to make interfacing well with modern technology (amps with ethernet ports) impossible. Sure, 3rd party code could probably handle volup/voldown events from tap, tap, tapping +/- onscreen, but why prevent using the pill to jump straight to the exact amp volume you want? Why make me open the cabinet and reach for the amp's volume knob? Are you limiting the product's utility to reduce the volume of support calls?

Thanks again for your candor.

** I'm not sure if this works with my code. Denon amps only respect volume commands if turned "on," and I don't know if the SBS alarm code changes the player power status before setting its volume. If not, a Denon amp control plugin might try setting the volume too soon.

*** Manufacturers that use digital volume control could set discrete codes for specific volumes, e.g. define one IR code for 10%, another for 20%, etc., and software like IR Blaster could then allow making rough discrete volume changes, but I don't know of any such IR codes. I don't know if vendors like NAD and Cambridge that only offer volup/voldown via their computer interfaces are being lazy, or if there's a technical limitation; perhaps their electronic volume control uses 80s style motorized pots that can't support setting specific volumes.

I'm marking this bug as fixed, as it fulfills the goals I set out for the scope of the 7.6.0 release. It provides a means for the user to choose fixed 100% volume, obeys replaygain and crossfade settings when used, and allows IR Blaster plugin to operate correctly.

I fully concede that this is a contentious choice, especially with Peter, but that is going to be the scope for the 7.6.0 release. I am open for coming up with a solution beyond 7.6.0 that can bring a "fictional" volume UI that can work with e.g. the Denon Serial plugin, but there's going to be very little movement on the idea that we would present a potentially confusing UI to people who accidentally have this setting set. In other words, the alternative UI would need to be present only in the presence of the plugin that needs it.

>but why prevent using the pill to jump straight to the exact amp volume you want?

because it presents a UI that doesn't make any sense to someone not using e.g. the Denon Serial plugin. User has set digital volume to 100%, and you can still manipulate volume levels on the UI even though it has no effect.

>Why make me open the cabinet and reach for the amp's volume knob? 

excuse my candor, but it's because what you are asking for has become an extremely corner use case now. Understand that our core customer now doesn't even have an amp, let alone a cabinet that an IR remote isn't sufficient for. My estimate is that after the current checkins for this bug to support fixed volume in 7.6.0, we are now talking about a 0.1%ish size of our total user base that will still be unsatisfied with what we're delivering.

I will admit that I don't have hard numbers to prove that, but if the work that's already been done on this bug is not enough and there's significant public outcry about that, I am very willing to reconsider that stance.
 
> Are you limiting the product's utility to reduce the volume of support calls?

I will quite plainly tell you that the management direction is to simplify our UI, even when it causes what would be perceived as a regression or limitation on the product utility. Where possible I've really tried to keep and/or enhance our product's feature set, but that is not what I'm being told to do on a daily basis now. Take it however you like, but I see no change in that direction, now or in the future.

If this is how it's to work with SP based players, there's one more detail that needs to be taken care of. Currently, the web UI permits the slider to move when volume is fixed at 100%. For consistency between interfaces, it should not be movable. It may undo some previous change for this bug, but if the Touch UI does not permit the slider to move, then the web interface also shouldn't.

Hopefully this can be achieved while maintaining the old behavior for ip3k players, where the volume slider can still be moved and can adjust the fictional volume level.

you may not like it, but that's out of scope for this bug. WebUI inconsistency would need a separate bug, and would not require a 7.6.0 target milestone. What I did on the squeezeplay side was to ignore any server driven volume changes (e.g. from the WebUI) when fixed volume was enabled.

It's not a matter of 'liking'. It's how it should work.

needs a bug then, go for it

There is now an option to set the volume to a fixed 100%   (build r32376 )