Who was it that wanted this feature?

Lots of people. Me, included.

Specifically, I wanted the volume ratio between the AM and FM bands changed. AM is way louder than FM.

Also, there is a built-in bass boost that works great on AM but is too much on FM.

Both of those things, I think, are bugs that should be corrected in the default player software...

I find it useful, so thanks! It's a nice fast feature, which is handy sometimes when you can't be bothered with a full eq tweak.

Ahh, I said Tuner, not Tone.

I'm implementing some Hijack changes that will allow people to automatically apply a volume boost or cut to the inputs, so that differences in AM/FM/AUX and MP3 levels can be overcome....ie when you set volume =xx it sounds the same volume regardless.

Although I'm glad that you appreciate the tone controls

Aye - I half understood, then:) I find the bass on FM much too loud, so I will quite happily alpha test. Is your patch a complete vol adjust per source, or does it have different Bass/Treb/Vol settings for AUX/DSP/AM/FM?

'Cos that would be perfect!

You see how easy it is to misunderstand things when you are reading 2 threads at once and being bored in a pointless conference call at the same time

... I find the bass on FM much too loud, so I will quite happily alpha test. Is your patch a complete
vol adjust per source

When it is a patch .

, or does it have different Bass/Treb/Vol settings for AUX/DSP/AM/FM?

Sorry no. Tone and Volboost are 2 separate features.

If anyone wants to decode the following, then it'd be relatively easy to decrease the FM bass boost:

			/* Load bank1 with bass boost:

			   Values calculated by cdsp.exe

                           +6db bass, 0db treble, first order cutoff 125Hz */

			dsp_write(Y_Ctl1,0x055);

			dsp_write(Y_Cth1,0x3ee);

			dsp_write(Y_Btl1,0x000);

			dsp_write(Y_Bth1,0x000);

			dsp_write(Y_At01,0x008);

			dsp_write(Y_At11,0x008);

			dsp_write(Y_At21,0x000);

			dsp_write(Y_KTrt1,0x4c4);

			dsp_write(Y_KTft1,0x662);

			dsp_write(Y_KTmid1,0x402);

			dsp_write(Y_KTbas1,0x47a);

			dsp_write(Y_KTtre1,0x000);

Oh! And there it is, hiding in plain sight. Bass/Treble controls in the hardware DSP..

	dsp_write(Y_KTbas1,0x47a);

	dsp_write(Y_KTtre1,0x000);

I think maybe somebody should play with those two registers, and see what they do.. This is the correct way to do Bass/Treble controls, independent of the Equalizer..

Cheers

Heh, I saw those, and thought that it was too obvious to be the real answer..

Tantalising isn't it.

There actually appears to be at least 2 separate tone control banks. The empeg currently uses bank0 for mp3,AM and AUX, presumably all set to off (as code comments indicate turning tone control 'off'), and bank1 for FM to apply a +6dB bass adjustment.

But, a quick hex-dec conversion of those numbers didn't reveal anything particularly revealing. I'm guessing that they are filter coefficients for an algorithm and not direct f,q,gain values. Maybe an engineering text book would help shed light on them...or maybe not.

Even if we did manage to work this out, we'd have to figure out what to do with the FM tone which currently has the +6dB bass applied (although this isn't insurmountable - we could use an eq for this).

One day.

It's not just those 2, unfortunately. There is a pre-cut to ensure that the bass/treble don't go into clipping; the pre-cut value is in the code snippet too though. It's a 24 bit fixed point DSP.

Draw your own conclusions

Hugo

Wait, are you telling me that there was never a bass boost applied to AM to begin with?

Darn, and here I was thinking AM was sounding particularly good on this tuner because of the bass boost.

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!

Awesome. I will try this out when I get home. I am so sick of having to turn my volume up and down when I switch between FM, AM, and MP3.

Oh, I put in a possible Tony bonus.

Well. Guess I'm going to have to try it, then.

/me looks forward to the day when the bass/treble boosts can be done directly to the DSP rather than modifying the equalizer curves.

Then again, the bass boost as you've implemented it currently sounds really good, you've picked a good set of parameters. So I dunno...

I haf vays ov mekin you test

Okay, test results:

Conditions:
- hijack244-volboost.zimage applied.
- Unit placed into the car for testing.
- config ini reads:

[hijack]

VoladjLow=0x1700,600,0x1000,200,600

disable_bassboost_FM=1

volume_boost_FM=2

volume_boost_AM=-6

volume_boost_AUX=2

When in the main MP3 player software, the volume response to a knob-turn was slow, and was accompanied by a stacatto muting of the volume with every click of the knob. L i i i k k e Th h h i i i s s s. Very very annoying.

When in the tuner, the volume did not have the stacatto muting, but it was very very slow to respond to a knob turn.

Whenever the input source was changed (say, going from MP3 to FM, or from FM to AM, or from FM to MP3), there was a very awful high-frequency POP! coming out of the speakers. Terribly high, excessively loud. I'm actually a little worried about my tweeters.

Hard to tell without some long-term tests, but it seemed as though the boost/cut and bassboost stuff was working, though. So if the other bugs can be squashed, we might be golden.

Hmm, the stacatto could be caused by debug printks - the slow default speed of the serial port in DC mode can slow the entire kernel. I thought I had turned these off, I'll check.

The pops...ok, I'll have to do a ramp up/down thing. I hope your tweeters aren't damaged.

Go back to something speaker-safe for the moment. I've got some code changes to make, probably late tonight, or tomorrow.

Thanks.

Ok.

Stacatto was being caused by debug printks. I had some #ifdef statements that should have been #if statements. Fixed.

Pops should now have gone away too. I reworked the code so that the volume boost is applied earlier when changing inputs. It is now applied whilst the mixer is muted. But start testing with the volume low anyway

New binary is hijack244-volboost-2.zimage

Got a kernel patch instead?

Give me a few minutes - I'm merging the changes into Hijack v246, and creating a patch against it.

Should I wait to test this version until you've got a 246 binary made for me?

Okay, I tried the 244 build and the stutter is gone as you said.

I still got a highfrequency pop when switching inputs. But only at first. After I messed with it a little while, the high pop stopped happening and was replaced by a low pop. Don't know why. I think it was after I started going to AM bands and back again. Doesn't really make sense.

Not certain, but I think the FM bass boost might still be there, despite my config.ini having the correct option to disable it.

I'm going to mess with the volume boost levels some more to make sure they're working.

volboost246.patch

Build in progress..

The pops are confusing. Now the volume boost is applied whilst the mixer is muted, so I would have expected any transient to disappear.

The only thing that I did wonder about is the eq and tone controls. The player applies an eq after the input changes, but AFAIK, it was the same eq as was previously set, so there shouldn't be any tone-related effects from this.

But maybe I should try reducing the tone controls to 0dB just before the input gets changed. They'll get reinitialised immediately after the change anyway.

I did the above tests with the tone adjustments at zero...

Ok, that's good to know....except I now can't see any way that my code could be causing the pops.

I'll keep looking.

Oh, were the pops as loud as before? ie, has anything changed?

Wait, wait, wait... now that I think about it...

Maybe that was it. Maybe what happened is that the pops ONLY happened when the tone adjustments were nonzero, and after they were zeroed, then the pops went away and all I heard was the normal faint low noise that happens when the player changes into and out of the FM or AM tuner band.

Can you confirm that?! I'm still not 100% happy with the tone controls anyway; although the functions that change the tone set 0dB before setting 'Off' and reapplying the old eq bands, thus stopping the pops when adjusting the eq around the zero point, when the selected eq is changed, any current tone control is just applied. Maybe I need to mute this event.

I thought that the selected eq was the same for all inputs, and that there weren't input-specific eqs. With this in mind, an input change should result in the same eq as previous...and I can't see how a transient could really occur due to this.

Can you confirm that?!

Confirmed.

When the bass adjust is at [OFF], there is no pop switching between sources, other than the normal bit of low frequency garbage you get as the tuner switches between AM and FM bands.

When the bass adjust is at +6db, there is a high-frequency pop when switching between Aux, Player, FM, and AM.

Cheers. Life would be so much easier with the dsp specs

Ok, I'm gonna classify that as a tone bug, and not a volume boost bug.

So hows the volume boost apart from that?