Mickey, I don't understand this, I'm not changing the volume linearly. Are you hearing it differently?

When I turn up the volume on 6430 firmware, I see these steps:

Muted
3
6
9
12
15
...

If you look at the Boom bug, you'll notice that the volume steps are much smaller at lower volumes. That was an issue brought up in Boom beta test that was solved by Caleb using the info in the Boom bug.

That's what you _see_, but is that what you hear? The actual difference between 3 and 6 and 6 and 9 are not the same. It's non-linear under the hood...

The volume is pretty wacky right now, it doesn't seem to respond correctly, so clearly something has to be done there.

I also agree that volume does not go quiet enough.  At night, in the bedroom, with headphones on, minimum is still pretty loud.  

But... This can be targeted even for PLD.  It's good enough for the moment.

-C

Sorry, that wasn't very clear was it?  My 'respond correctly', I mean that the volume doesn't respond to turning the knob in a prompt manner.  And sometimes it seems to loose clicks all together.

So, if I'm all the way down at 'mute', and click 1 detent clockwise, I expect to not be at mute anymore.  But that doesn't work for me.

Let me add on to what Caleb said. When I go 1 click above mute, it's too loud for what I expect. 2 clicks is the same, too.

I expect a slow volume ramp for each click I go above mute.

cc:ing Tom, who did some recent changes for volume knob responsiveness. Not sure it's exactly the issue, but it might be good to go from 0 to 1 instead of 0 to 3, and that is part of that change.

Later tonight, I'll try 0-1 then 1-4, 4-7 etc....

also, there is existing rate limiting in place to avoid sending too many volume commands to the server. This will be improved and also local control of volume for local players will be added.

Created attachment 5432 [details]
Table of attenuation steps

See attachment for the db steps used in a commercially available stepped attenuator.

With r6444, I make it so the first level after the bottom is 1, so for knob entry, the follow would occur from muted for each knob event:
(muted), 1, 4, 7, 10, 13, etc...
Behind the scenes this then calls to the server which determines the actual attenuation per step. I found that 1 is still not extremely quite coming out of a classic with headphones on, but it's always been that way for a volume level of 1.


Richard had asked me to look in to making the volume knob more responsive. I made a few quick improvements to the rate limiting and made the knob move in steps of 3. The rate limiting still needs more improvement and also local volume control is in place.  Putting aside the still poor rate limiting algorithm in place now (which avoids sending too many volume commands to the server in a short period of time),  I'd like feedback on the choice to use a step of 3 at all for baby knob, since I put it in based on my personal feelings about what I think the mainstream user would expect (and a bit of Richard's encourangement). You can still test the full functionality by not turning too fast, thus avoiding the rate limiting, or by using the In Store Demo.

What I found with the In Store Demo Applet (where we do direct local volume control, thus avoiding any rate limiting issues) was that when I did 1 step/event, for a typical turn, the volume barely had a perceptible change. By a typical turn a mean a 180 degree turn, which causes about 12 events to occur.

My reasoning:
I can see a small percentage of the users really wanting the fine grained control of 1 step/event (which they can still get with the remote where acceleration applies, starting slowly by 1), but I think the mainstream user is used to more direct feedback with volume knobs.

Look at Boom.pm for how Boom volume 0->100 is controlled in terms of dB.  That works well, and i'm not sure anybody has a problem with that.  It goes quiet enough, 50% is pretty resonable. 

Then the question is how to map knob turning to the 0->100 scale.  That's the trick.  How many ticks/rotation do we have?  I think it's 24.  Clearly, 4*24 ~= 100, is clearly no good.  We can't expect 4 complete rotations of the knob to get from 0 to 100.  

Perhaps it needs to be speed dependent.  I think it's not too bad on Boom.  Maybe that should be a starting point.

-C

I see, there's a different curve and different lowest setting for Boom. I didn't realize that. SP LocalPlayer uses the audg value sent from the server to set the volume. I'm guessing SP is getting the getVolumeParameters from Squeezebox2.pm, which has:
totalVolumeRange => -50,    # dB, for example.

To have the curve behave more like Boom, either we need to 
a) have getVolumeParameters server side handling for Baby that match/are similar to Boom
b) Have SP have local volume curve calculation, which would mean not using the audg value, but rather the 0-100 value (that may come locally or from a remote source)  

Ultimately, we'll have to do a local curve calculation for local volume control to work, though, so (b) seems like the right direction. I will plan to duplicate the Boom code as a starting point for that.

I tried the Boom volume steps on the In Store Demo. There's a big difference and I think going 1 step/event works well with the Boom curve. I'll switch back to one step per event, and count on use getting the Boom curve into Baby one way or another...

Ah great.  I spent some time getting the boom curve good, so I'm glad that helps.

Volume control is definitely something that has to be handled on a per-player-model basis.  We'll see this even more as we make  more products.  For that matter, different outputs of each product may require different curves.  A line-out may want to be pretty linear (in dB of course) with volueme, whereas speakers maybe something else.  

-C

In firmware r6526, the volume knob has 100 increments. On the Baby hardware, it takes over 3 complete revolutions to go from 0 to 100.

That's different than the traditional analog volume knob, which has travel from the off position at 7 o'clock clockwise to maximum volume at 5 o'clock. I would suggest mapping the volume increments to allow the user to go from one extreme to the other with this range of travel.

From what I can tell, there's about 24 knob clicks going between those points. That's the number of clicks in the table used for the analog volume control in the attachment to this bug. I would suggest somehow mapping each Baby knob click to those values.

Tom, punting this your way. This is turning into a damned if you do, damned if you don't thing.

Tom had put in code to have the vol knob be more responsive by going by steps of 3 instead of 1 with each detent, but that was scrapped because those steps were too big at low levels. So, we're now doing 1 step per detent, and it takes several turns of the knob to get from 0 to 100.

We don't have a clear definition of how this is supposed to work. Who should we bring in on this? Weldon?

Yeah this is a bit of a tough nut to crack.  I suspect there will be some knob speeds sensing going on. 

I really don't think it should take more than 2 or so fast twists of the knob to go from mute to full volume, but we also need fine grained control.  

I suspect itsgoing to take a day or two of playing around with different alternatives to figure out what is natural feeling, and effecive.

Aha ha.  i just found a use for volume press-- fine grained volume adjustment.   Alright.... maybe thats not such a good idea, but it might be worth trying.

*** Bug 12938 has been marked as a duplicate of this bug. ***

Reset priority before triage.

Plan is to move to the Boom volume curve as part of local volume control

now uses Boom curve for local player.

Reopening to discuss in bug meeting. Previous CX review complained about too many turns of volume knob to set volume at user-desired level.

Please invite me for this discussion.  This directly relates to audio perception (and perhaps acceleration).

Mickey, do you know roughly which FW version previous CX review complained about? Volume behavior has changed along the way.

I'll try to make volume function similar to Boom, including acceleration.

== Auto-comment from SVN commit #7568 to the jive repo by tom ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7568 ==

Fixed Bug: 12729
- support volume acceleration on baby
- baby vol events now send event time not time from bsp processing, allowing
reasonable velocity calculation

The volume knob behavior now works more like Boom:
- Gentle turns move volume by one per detent. Each 180 degree rotation is about 12 detents. So it takes about 9 slow 180 degree turns to go from 0 to 100
- Takes about 5 medium fast 180 degree turns to move from 0 to 100
- Takes about 2 fast 180 degree turns to move from 0 to 100

This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.