That's what I'm saying.

Anyway, Here is a kernel binary containing alpha "Volume Boost" code. It is based on hijack v244, but also contains the tone fixes from v245.

Usage is fairly simple - in your config.ini:

[hijack]

volume_boost_FM=nn

volume_boost_AM=nn

volume_boost_AUX=nn

nn is an integer, -100<=nn<=100 that describes the number of volume steps to boost (+ve) or cut (-ve) the volume for that particular input, referenced to the absolute volume that the player sets. These values all default to 0 if you don't put the line in, and usable values are likely to be below 10 in magnitude. The best way to find your values is to start with them all zero, set your volume to a typical level whilst listening to an mp3, change inputs and count the number of volume steps it takes to get the volume the same as it was. Repeat for other inputs You will probably find that this process is iterative, and the first time you do this the values you end up with might be close but not perfect.

Whenever you change input, or change volume, the new code calculates a boosted volume value and applies it. As far as the player is concerned, this code does not exist - ie, if you set volume to -6dB whilst listening to an mp3, when you change to FM radio, the player still thinks the volume is -6dB, even though the boosted/cut volume may be different.
The calculation ensures that the boosted value does not exceed the mixers allowable volume range. It does this with a hard limit at the maximum value - so as the volume applied by the player approaches the maximum, the amount of boost decreases. So, I don't want to see bug reports along the lines of "When I set my volume to max, my +14 FM volume boost doesn't work"!

I don't have a tuner, and my AUX in wires are lost in the canyons of my dash, so my ability to test this is limited to watching various debug values on the serial port (debug is off in this binary though). So I need someone to actually try and abuse this code and give me some feedback.

One thing that I am interested in is how the non-linearity of the volume table may affect this feature. The volume steps in the empeg change across the volume range, so a +4 step may equate to +6dB at one end of the scale, but only +4dB at the other. This may mean that if you balance your volumes at 0dB that they are too unbalanced at -20dB, and vice versa. It might be that if you balanced at -10dB that it remains ok across your typical listening range. I want to avoid having to do iterative volume table lookups in order to use dB values as the parameter instead of volume steps, but if it is necessary then I'll have to. Let me know please.


Oh, I put in a possible Tony bonus.

[Hijack]

disable_bassboost_FM=1

We don't know how to change the +6db bass boost to +3dB, but we can try turning it off, and see how that sounds


As before with the tone stuff, the implementation details of this feature are prone to modification until stable!