Dithered volume control for Squeezebox

[darrenyeats]

Adjusting volume (scaling the data) is never bit perfect (except at full volume, when there is no scaling/adjustment) by definition.

Ooh, you know what I meant Julf! Thanks - original post edited.

[Wombat]

Adjusting volume (scaling the data) is never bit perfect (except at full volume, when there is no scaling/adjustment) by definition.

One exception is shifting bitwise.
http://forums.slimdevices.com/showth...-volume-change

[Mnyb]

re gain staging for use without preamp for example . What you usually do is to adjust the analog gain of the system so that 90-100 of the digital volume is your loudest ever listening level but not louder .

You can do that with passive attenuators , adjustable power amps , adjustable outputs on the DAC ( like transporter )

[arnyk]

Dither is still the correct way to do volume control ...! Because I want to play anything, over a usable volume range, without worrying about it.

I'll add something here. Though I accept you might live within the limits of the SB and Transporter volume controls, I'm not sure about the Touch ...!

I'm given to understand it's SqueezePlay that runs on the Touch, is this true? From what I've seen of the SqueezePlay code, it uses a two part scale where 0=-74db, 25=-37dB and 100=0db and volume steps divided equally in dB in each scale. You can see the first part ramps rapidly. This actually fits with my user experience with the Touch. Until someone can explain otherwise, (edit*) I think the Touch likely truncates at every volume level below 100, with 16 or 24 bit sources.
Darren

*Thanks Julf.

I'll add something here. There is something called self-dither. Most commercial recordings have so much built-in random noise that they effectively dither the downstream reproduction chain and cover up any stages that should be dithered but aren't. This would probably become apparent if DBTs were used to evaluate the issues raised in this thread.

[pippin]

Dither is still the correct way to do volume control ...! Because I want to play anything, over a usable volume range, without worrying about it.

I'll add something here. Though I accept you might live within the limits of the SB and Transporter volume controls, I'm not sure about the Touch ...!

I'm given to understand it's SqueezePlay that runs on the Touch, is this true? From what I've seen of the SqueezePlay code, it uses a two part scale where 0=-74db, 25=-37dB and 100=0db and volume steps divided equally in dB in each scale. You can see the first part ramps rapidly. This actually fits with my user experience with the Touch. Until someone can explain otherwise, (edit*) I think the Touch likely truncates at every volume level below 100, with 16 or 24 bit sources.
Darren

*Thanks Julf.

That's only half true.
1. Yes, SqueezePlay does have two overlapping volume ramps and there's actually even a volume level at which increasing the "logical" volume level by one decreases the actual volume level (between step 38 and 39 I believe... might have mis-counted by one or two, though ).
The reason for this is that you want different levels of volume change for high and low relative volume levels. A "linear" (of course it's actually logarithmic) change would either have too big steps at high volume levels or too small steps at low levels.
So if you don't like the ramp using an external volume control might help.

2. SqueezePlay doesn't necessarily clip with 16 bit material.
EDIT: my original assumption (remembering the table wrongly) was that it uses the remaining 8 bit to scale but it doesn't, it uses a 16 bit volume range because -48 dB would probably not be silent enough.
I haven't checked which ones of the volume steps potentially clip, obviously all that go beyond -48 dB do but there are only 17 of those (steps 0 to 16). If you want to optimize for clipping it might be worthwhile to optimize this table. It's in the lua source code so you can actually do that.
EDIT2: OK, I re-checked again and as it stands the whole upper volume range is already optimized for this. So that whole upper part of the curve (down to level 39) does NOT have any clipping for 16 bit values because it only uses the upper 8 bit of the volume factor.
Between level 38 and 39 the scale changes (39 equates to a lower actual volume level than volume step 38) and below that (for more silent volume levels) you will see clipping at -144dB.

3. For 24 bit material EVERY volume control will clip, even a dithering one.
It does clip at -144dB, though so if any your dithering effect will be a noise "optimization" (it's not a reduction because as mentioned before dithering itself is just adding noise, too) of -147dB. Worthwhile all the hassle?

[darrenyeats]

Pippin, I've seen such custom tables but are you SURE that SqueezePlay uses such a table? Because the code has a parameter for the total volume range (74dB) that can be set to any value. Also parameters for the ramping. I infer there is no mapping to a custom table like for SB/Transporter.


I didn't write linear, I wrote equally divided by dB, which is itself a logarithmic scale.
Darren

[darrenyeats]

I'll add something here. There is something called self-dither. Most commercial recordings have so much built-in random noise that they effectively dither the downstream reproduction chain and cover up any stages that should be dithered but aren't. This would probably become apparent if DBTs were used to evaluate the issues raised in this thread.

Right. Plus the studio probably does all sorts of processing at high accuracy and sampling rate - when they reduce effective bit depth for the 16/44 file they'll have to add dither at 16 bits.

Still, correctly implemented digital volume control will handle any recording, at 16 or 24 bits, at any volume level, without adding any digital distortion.

[pippin]

Pippin, I've seen such custom tables but are you SURE that SqueezePlay uses such a table?

Yes, I am sure.
The player even matches gain values coming from the server (e.g. when using replay gain or fade-in/-out) to the table and picks a matching gain value from the table.

Because the code has a parameter for the total volume range (74dB) that can be set to any value. Also parameters for the ramping. I infer there is no mapping to a custom table like for SB/Transporter.

Where did you find that? Applets can override this behavior but I haven't found any one that does.

Could it be that what you found is for the volume control and defines the stepping of the volume buttons/scale? That would still then be translated based on this curve by the player.
Player and UI are separate logical entities in SqueezePlay (the UI can connect to a remote player, for example).

I didn't write linear, I wrote equally divided by dB, which is itself a logarithmic scale.

But _I_ wrote linear and wanted to make sure it's clear that what I meant was a linear curve for the dB values which then represent a logarithmic energy scale

[darrenyeats]

Pippin,
So the table is in a firmware layer on (say) the Touch? And the table translates incoming dB/scaling values to the nearest scaling value that matches in its table? (BTW, if that were true, technically the table wouldn't be in SqueezePlay.)

Thanks, Darren

PS: I ask out of curiosity only, since I listen over wide volume range and I have 24 bit music ...

[pippin]

It's not in the firmware, it's in SqueezePlay. Both technically and really. It's in Playback.lua which is the player code.
It's not overridden per device which came as a surprise to me because I had considered the Touch might have a different curve from Radio or Controller. This is actually the curve originally coming from the Boom. I believe SB3 and Transporter have different curves.