Balance

[philippe_44]

I didn't realize you meant you made a mistake in the code. I just thought you made a typo in the post.

No and this is what is sad and embarassing: I just coded something stupid and happily wrote the same... as said, I'll probably stop for a while

I just downloaded the latest LMS update, and the values look like they are corrected. However, the gainL/gainR values are normally based on the volume curve of the SB Boom so 0.96 gain is actually 52224 not 62914. I guess I could detect for balance changes and calculate the gain differently when that happens, but I think having it the balanced values be consistent with the normal values would be nicer.

In case you need it, here's the array I use for converting the values:

0, 16, 18, 22, 26, 31, 36, 43, 51, 61, 72, 85, 101, 120, 142, 168, 200, 237, 281, 333, 395, 468, 555, 658, 781, 926, 980, 1037, 1098, 1162, 1230, 1302, 1378, 1458, 1543, 1634, 1729, 1830, 1937, 2050, 2048, 2304, 2304, 2560, 2816, 2816, 3072, 3328, 3328, 3584, 3840, 4096, 4352, 4608, 4864, 5120, 5376, 5632, 6144, 6400, 6656, 7168, 7680, 7936, 8448, 8960, 9472, 9984, 10752, 11264, 12032, 12544, 13312, 14080, 14848, 15872, 16640, 17664, 18688, 19968, 20992, 22272, 23552, 24832, 26368, 27904, 29696, 31232, 33024, 35072, 37120, 39424, 41728, 44032, 46592, 49408, 52224, 55296, 58624, 61952, 65536

This was copied from the SqueezePlay code.

I just went for the simplest (or stupidest) but I think this does not matter much. The span of 25 is very arbitrary anyway. Do you really think that having the same ratio whatever the volume is will produce such an unpleasant effect, i.e. balance will sound good at some volume but bad at others?

I have a Transporter. Balance is working.

Thx

[Ron F.]

Philippe, your mistake is one that anybody could have made, anybody, easy to do. It is NOT a big deal whatsoever!

Things like this happen all the time. When you commit code, we are your QA/Testing department, and we love to do it!

I remember one of my "company name removed" stories, about somebody driving a probe into the surface of Mars waaaaaaaaay too fast, due to a trivial math error That blemish mankind left on Mars might be there for millions of years. And now, I would like to introduce you to some self-driving automobiles!

[RobbH]

No and this is what is sad and embarassing: I just coded something stupid and happily wrote the same... as said, I'll probably stop for a while....

Philippe, I don't want to make light of your distress. I sort of understand, even though I'm not capable of doing the work you're doing on LMS. I think you certainly should take a break, not as punishment, but just to have an opportunity to take a few deep breaths and think about things other than code for a while.

But with all that, I'm still the sort of guy who can't resist a setup like this, so I hope you'll at least get a smile out of it:

Relax, man! It's just a mistake! No need to get all UNBALANCED about it!

[wt0]

No and this is what is sad and embarassing: I just coded something stupid and happily wrote the same... as said, I'll probably stop for a while


I just went for the simplest (or stupidest) but I think this does not matter much. The span of 25 is very arbitrary anyway. Do you really think that having the same ratio whatever the volume is will produce such an unpleasant effect, i.e. balance will sound good at some volume but bad at others?


Thx

I'm not saying that the ratio matters, 25 is fine. It's the values that are being sent by the server do not increase or decrease in a linear manner. They follow the progression of that list of numbers and there are 101 values. So, for example, it you set the volume to 96, instead of sending 65536 * 0.96 = 62914, it sends 52224. So when the player receives the value, instead of just dividing the raw value by 65536 to get the gain, it looks for the closest value in the array and uses the index of the item as the gain.

Edit: I was assuming 100% volume, so that formula was wrong.

[wt0]

You should convert gainL/gainR to and integer using the table, apply the gain adjustment to that value then use it as the index in the table to find to correct fixed point value.

So for lets say volume is set to 96 and balance is 5, gainL would be 52224 and gain adjustment would be (25-5)/25 = 0.80. Find 52224 in the table which will give you and index of 96. Multiply 96 by 0.80 to get 76.8. I usually just floor the value to 76. Then use 76 as the index to get value in the table which is 16640.

[philippe_44]

I'm not saying that the ratio matters, 25 is fine. It's the values that are being sent by the server do not increase or decrease in a linear manner. They follow the progression of that list of numbers and there are 101 values. So, for example, it you set the volume to 96, instead of sending 65536 * 0.96 = 62914, it sends 52224. So when the player receives the value, instead of just dividing the raw value by 65536 to get the gain, it looks for the closest value in the array and uses the index of the item as the gain.

For you to implement it, it's very simple. Just take the gain adjustment multiply it by 100 and use the value at that index on the list. So, for example, if the balance is set to 5, you'll use your formula, (25-5)/25 = 0.8 multiply by 100 to get 80. Then just take the value at index 80 from the array, which is 20992

I'm probably thick again but then I don't think this is the right thing to do then. The 0..100 to 16 bits is not tabulated but interpolated using parameters that are defined by squeezebox2.pm or its descendants (e.g. squeezeplay.pm and boom.pm define it differently). So if I force tabulation, I'll void what other descendants might do. Also, in your example, 5 means only use (25-5)/25=80% of volume for Left and 100% for Right but does not mean 20992 should be sent as gainL.

If I really want comply to the segmented volume curve, the balance ratio should be applied to the dB volume (0..100) and then the get_volume and dBToFixed applied individually (i.e. 5 means I apply 80% of the required (0..100) volume to Left and still 100% to Right). Now, I never paid too much attention to that domain of audio, but is a log balance the right thing to do? I though back in the old days of analogue, linear potentiometers were used because we want a finer sensitivity of the balance around the center.

if (defined($newvolume)) {
		my $balance = $prefs->client($client)->get('balance') || 0;
		my $left = $balance > 0 ? (25 - $balance) / 25 : 1;
		my $right = $balance < 0 ? (25 + $balance) / 25 : 1;
		
		# Old style volume:
		my $oldGainL = $volume_map[int($volume*$left)];
		my $oldGainR = $volume_map[int($volume*$right)];

		my ($newGainL, $newGainR);
		# Negative volume = muting
		if ($volume <= 0) {
			$newGainL = $newGainR = 0;
		}
		else {
			my $db = $client->getVolume($volume*$left, $client->getVolumeParameters());
			$newGainL = $client->dBToFixed($db);
			$db = $client->getVolume($volume*$right, $client->getVolumeParameters());
			$newGainR = $client->dBToFixed($db);
		}

		my $dvc = $prefs->client($client)->get('digitalVolumeControl');
		if ( !defined $dvc ) {
			$dvc = $Slim::Player::Player::defaultPrefs->{digitalVolumeControl};
		}

		my $preamp = 255 - int( 2 * ( $prefs->client($client)->get('preampVolumeControl') || 0 ) );
		my $data;

		if (defined($client->controllerSequenceId())) {
			$data = pack('NNCCNNNa6', $oldGainL, $oldGainR, $dvc, $preamp, $newGainL, $newGainR,
				($client->controllerSequenceNumber() || 0), $client->controllerSequenceId());
		}
		elsif (defined($client->sequenceNumber())) {
			$data = pack('NNCCNNN', $oldGainL, $oldGainR, $dvc, $preamp, $newGainL, $newGainR, $client->sequenceNumber());
		}
		else {
			$data = pack('NNCCNN', $oldGainL, $oldGainR, $dvc, $preamp, $newGainL, $newGainR);
		}
		$client->sendFrame('audg', \$data);
	}

Which also reminded me that SqueezeSlave is doing its own volume method implementation... crap. Is this still in use today?

[philippe_44]

Philippe, your mistake is one that anybody could have made, anybody, easy to do. It is NOT a big deal whatsoever!

Things like this happen all the time. When you commit code, we are your QA/Testing department, and we love to do it!

I remember one of my "company name removed" stories, about somebody driving a probe into the surface of Mars waaaaaaaaay too fast, due to a trivial math error That blemish mankind left on Mars might be there for millions of years. And now, I would like to introduce you to some self-driving automobiles!

If remember the Mars one at least they had the excuse of metric & imperial

Philippe, I don't want to make light of your distress. I sort of understand, even though I'm not capable of doing the work you're doing on LMS. I think you certainly should take a break, not as punishment, but just to have an opportunity to take a few deep breaths and think about things other than code for a while.

But with all that, I'm still the sort of guy who can't resist a setup like this, so I hope you'll at least get a smile out of it:

Relax, man! It's just a mistake! No need to get all UNBALANCED about it!

It worked

Thanks guys - always look at the bright side of life

[wt0]

I'm probably thick again but then I don't think this is the right thing to do then. The 0..100 to 16 bits is not tabulated but interpolated using parameters that are defined by squeezebox2.pm or its descendants (e.g. squeezeplay.pm and boom.pm define it differently). So if I force tabulation, I'll void what other descendants might do. Also, in your example, 5 means only use (25-5)/25=80% of volume for Left and 100% for Right but does not mean 20992 should be sent as gainL.

Yeah, I was wrong. I realized that i was assuming 100% volume. I suggested something else afterward.

If I really want comply to the segmented volume curve, the balance ratio should be applied to the dB volume (0..100) and then the get_volume and dBToFixed applied individually (i.e. 5 means I apply 80% of the required (0..100) volume to Left and still 100% to Right). Now, I never paid too much attention to that domain of audio, but is a log balance the right thing to do? I though back in the old days of analogue, linear potentiometers were used because we want a finer sensitivity of the balance around the center.

I'm not really sure what's right, I'm not really an expert in analogue. I made the suggestion mostly so that the coding on my end would be more consistent, so I won't have to convert the balance adjusted values differently than the normal volume values.

Which also reminded me that SqueezeSlave is doing its own volume method implementation... crap. Is this still in use today?

You're probably OK to ignore SqueezeSlave. I highly doubt that anyone still uses it. Can you even get SqueezeSlave anymore?

[bpa]

If I really want comply to the segmented volume curve, the balance ratio should be applied to the dB volume (0..100) and then the get_volume and dBToFixed applied individually (i.e. 5 means I apply 80% of the required (0..100) volume to Left and still 100% to Right). Now, I never paid too much attention to that domain of audio, but is a log balance the right thing to do? I though back in the old days of analogue, linear potentiometers were used because we want a finer sensitivity of the balance around the center.

This may be a minefield. IIRC when developers were defining/modifiying the curve - a lot of user feedback was that fine control at very low volume was needed esp when listening at night/early morning typically in bed.
When channels are not balanced then at some point in low volume one channel will not be heard at all. Users will have to accept that or else you'll have a complicated solution.

[slartibartfast]

Will balance be maintained as volume is changed?

Sent from my Pixel 3a using Tapatalk