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?

So hows the volume boost apart from that?

I think it's doing what it's supposed to do, not 100 percent certain.

When I say "-6" in the ini-file, how much does that translate to in decibels of attenuation? How high or low can I go with it?

My goal was to reduce the AM volume by a significant amount, and boost the FM slightly.

I described it in the earlier post: Simple answer: +6 equates to +3dB, ie 0.5dB per integer.

Long answer:

The player doesn't really know about dB levels when it sets the volume. There is a table of 100 volume levels, and the player just moves to the previous/next entry in the table and applys it in order to decrease/increase the volume. It then reads back the dB value associated with that row in tha table to send to the display so that the user can say "My volumes set to xx dB". So the way that the boost works at the moment by jumping up or down nn rows in the table where nn is the config.ini parameter.So +6 equates to pressing "vol up" 6 times or rotating the knob slowly 6 clicks clockwise.

I also mentioned that I needed feedback on the non-linearity issue. This is because the table is non-linear. Right at the bottom of the scale, we start with approximately 3dB per step, and above -3dB, it is 1dB per step.

But for most of the useful range (-25dB to -3dB), it is approximately 0.5dB per step. Because it is 0.5dB for so much of the range, it doesn't make much sense for me to write code to take a dB value from config.ini and iteratively find the row that is nearest to it. I'd have to get the current volume, read the assosciated dB value, add the config.ini dB value, and then read the table until I found the line. Granted, this could be done without too many coding nightmares, but it doesn't really seem worth it if I can just do integer math on the table index with acceptable results.

Here is the table so you can see what I'm talking about:

	{ 0x000, 0xf80, -9999 }, /* Zero */

	{ 0xfff, 0xf80, -6620 }, /* -66.2 dB intensity 0.023988 */

	{ 0xffe, 0xf80, -6270 }, /* -62.7 dB intensity 0.053703 */

	{ 0xffd, 0xf80, -5820 }, /* -58.2 dB intensity 0.151356 */

	{ 0xffc, 0xf80, -5530 }, /* -55.3 dB intensity 0.295121 */

	{ 0xffb, 0xf80, -5310 }, /* -53.1 dB intensity 0.489779 */

	{ 0xffa, 0xf80, -5140 }, /* -51.4 dB intensity 0.724436 */

	{ 0xff9, 0xf80, -4990 }, /* -49.9 dB intensity 1.023293 */

	{ 0xff8, 0xf80, -4870 }, /* -48.7 dB intensity 1.348963 */

	{ 0xff7, 0xf80, -4760 }, /* -47.6 dB intensity 1.737801 */

	{ 0xff6, 0xf80, -4660 }, /* -46.6 dB intensity 2.187762 */

	{ 0xff5, 0xf80, -4580 }, /* -45.8 dB intensity 2.630268 */

	{ 0xff4, 0xf80, -4500 }, /* -45.0 dB intensity 3.162278 */

	{ 0xff3, 0xf80, -4420 }, /* -44.2 dB intensity 3.801894 */

	{ 0xff2, 0xf80, -4360 }, /* -43.6 dB intensity 4.365158 */

	{ 0xff1, 0xf80, -4290 }, /* -42.9 dB intensity 5.128614 */

	{ 0xff0, 0xf80, -4240 }, /* -42.4 dB intensity 5.754399 */

	{ 0xfef, 0xf80, -4180 }, /* -41.8 dB intensity 6.606934 */

	{ 0xfed, 0xf80, -4080 }, /* -40.8 dB intensity 8.317638 */

	{ 0xfeb, 0xf80, -3990 }, /* -39.9 dB intensity 10.232930 */

	{ 0xfe9, 0xf80, -3910 }, /* -39.1 dB intensity 12.302688 */

	{ 0xfe7, 0xf80, -3840 }, /* -38.4 dB intensity 14.454398 */

	{ 0xfe4, 0xf80, -3740 }, /* -37.4 dB intensity 18.197009 */

	{ 0xfe1, 0xf80, -3650 }, /* -36.5 dB intensity 22.387211 */

	{ 0xfde, 0xf80, -3570 }, /* -35.7 dB intensity 26.915348 */

	{ 0xfdb, 0xf80, -3490 }, /* -34.9 dB intensity 32.359366 */

	{ 0xfd8, 0xf80, -3420 }, /* -34.2 dB intensity 38.018940 */

	{ 0xfd5, 0xf80, -3360 }, /* -33.6 dB intensity 43.651583 */

	{ 0xfd2, 0xf80, -3300 }, /* -33.0 dB intensity 50.118723 */

	{ 0xfcf, 0xf80, -3250 }, /* -32.5 dB intensity 56.234133 */

	{ 0xfcb, 0xf80, -3180 }, /* -31.8 dB intensity 66.069345 */

	{ 0xfc7, 0xf80, -3110 }, /* -31.1 dB intensity 77.624712 */

	{ 0xfc3, 0xf80, -3050 }, /* -30.5 dB intensity 89.125094 */

	{ 0xfbf, 0xf80, -3000 }, /* -30.0 dB intensity 100.000000 */

	{ 0xfbb, 0xf80, -2950 }, /* -29.5 dB intensity 112.201845 */

	{ 0xfb7, 0xf80, -2900 }, /* -29.0 dB intensity 125.892541 */

	{ 0xfb3, 0xf80, -2850 }, /* -28.5 dB intensity 141.253754 */

	{ 0xfaf, 0xf80, -2810 }, /* -28.1 dB intensity 154.881662 */

	{ 0xfab, 0xf80, -2760 }, /* -27.6 dB intensity 173.780083 */

	{ 0xfa7, 0xf80, -2720 }, /* -27.2 dB intensity 190.546072 */

	{ 0xfa2, 0xf80, -2680 }, /* -26.8 dB intensity 208.929613 */

	{ 0xf9e, 0xf80, -2640 }, /* -26.4 dB intensity 229.086765 */

	{ 0xf99, 0xf80, -2600 }, /* -26.0 dB intensity 251.188643 */

	{ 0xf93, 0xf80, -2550 }, /* -25.5 dB intensity 281.838293 */

	{ 0xf8d, 0xf80, -2500 }, /* -25.0 dB intensity 316.227766 */

	{ 0xf86, 0xf80, -2450 }, /* -24.5 dB intensity 354.813389 */

	{ 0xf7f, 0xf80, -2400 }, /* -24.0 dB intensity 398.107171 */

	{ 0xf77, 0xf80, -2350 }, /* -23.5 dB intensity 446.683592 */

	{ 0xf6f, 0xf80, -2300 }, /* -23.0 dB intensity 501.187234 */

	{ 0xf66, 0xf80, -2250 }, /* -22.5 dB intensity 562.341325 */

	{ 0xf5d, 0xf80, -2200 }, /* -22.0 dB intensity 630.957344 */

	{ 0xf54, 0xf80, -2150 }, /* -21.5 dB intensity 707.945784 */

	{ 0xf49, 0xf80, -2100 }, /* -21.0 dB intensity 794.328235 */

	{ 0xf3f, 0xf80, -2050 }, /* -20.5 dB intensity 891.250938 */

	{ 0xf33, 0xf80, -2000 }, /* -20.0 dB intensity 1000.000000 */

	{ 0xf27, 0xf80, -1950 }, /* -19.5 dB intensity 1122.018454 */

	{ 0xf1a, 0xf80, -1900 }, /* -19.0 dB intensity 1258.925412 */

	{ 0xf0d, 0xf80, -1850 }, /* -18.5 dB intensity 1412.537545 */

	{ 0xefe, 0xf80, -1800 }, /* -18.0 dB intensity 1584.893192 */

	{ 0xeef, 0xf80, -1750 }, /* -17.5 dB intensity 1778.279410 */

	{ 0xedf, 0xf80, -1700 }, /* -17.0 dB intensity 1995.262315 */

	{ 0xece, 0xf80, -1650 }, /* -16.5 dB intensity 2238.721139 */

	{ 0xebb, 0xf80, -1600 }, /* -16.0 dB intensity 2511.886432 */

	{ 0xea8, 0xf80, -1550 }, /* -15.5 dB intensity 2818.382931 */

	{ 0xe94, 0xf80, -1500 }, /* -15.0 dB intensity 3162.277660 */

	{ 0xe7e, 0xf80, -1450 }, /* -14.5 dB intensity 3548.133892 */

	{ 0xe67, 0xf80, -1400 }, /* -14.0 dB intensity 3981.071706 */

	{ 0xe4f, 0xf80, -1350 }, /* -13.5 dB intensity 4466.835922 */

	{ 0xe36, 0xf80, -1300 }, /* -13.0 dB intensity 5011.872336 */

	{ 0xe1a, 0xf80, -1250 }, /* -12.5 dB intensity 5623.413252 */

	{ 0xdfe, 0xf80, -1200 }, /* -12.0 dB intensity 6309.573445 */

	{ 0xddf, 0xf80, -1150 }, /* -11.5 dB intensity 7079.457844 */

	{ 0xdbf, 0xf80, -1100 }, /* -11.0 dB intensity 7943.282347 */

	{ 0xd9d, 0xf80, -1050 }, /* -10.5 dB intensity 8912.509381 */

	{ 0xd78, 0xf80, -1000 }, /* -10.0 dB intensity 10000.000000 */

	{ 0xd52, 0xf80, -950 }, /* -9.5 dB intensity 11220.184543 */

	{ 0xd29, 0xf80, -900 }, /* -9.0 dB intensity 12589.254118 */

	{ 0xcfe, 0xf80, -850 }, /* -8.5 dB intensity 14125.375446 */

	{ 0xcd1, 0xf80, -800 }, /* -8.0 dB intensity 15848.931925 */

	{ 0xca0, 0xf80, -750 }, /* -7.5 dB intensity 17782.794100 */

	{ 0xc6d, 0xf80, -700 }, /* -7.0 dB intensity 19952.623150 */

	{ 0xc37, 0xf80, -650 }, /* -6.5 dB intensity 22387.211386 */

	{ 0xbfe, 0xf80, -600 }, /* -6.0 dB intensity 25118.864315 */

	{ 0xbc1, 0xf80, -550 }, /* -5.5 dB intensity 28183.829313 */

	{ 0xb80, 0xf80, -500 }, /* -5.0 dB intensity 31622.776602 */

	{ 0xb3c, 0xf80, -450 }, /* -4.5 dB intensity 35481.338923 */

	{ 0xaf4, 0xf80, -400 }, /* -4.0 dB intensity 39810.717055 */

	{ 0xa56, 0xf80, -300 }, /* -3.0 dB intensity 50118.723363 */

	{ 0x9a5, 0xf80, -200 }, /* -2.0 dB intensity 63095.734448 */

	{ 0x8df, 0xf80, -100 }, /* -1.0 dB intensity 79432.823472 */

	{ 0x800, 0xf80, 0 }, /* 0.0 dB intensity 100000.000000 */

	{ 0x800, 0xf70, 100 }, /* 1.0 dB intensity 125892.541179 */

	{ 0x800, 0xf5f, 200 }, /* 2.0 dB intensity 158489.319246 */

	{ 0x800, 0xf4b, 300 }, /* 3.0 dB intensity 199526.231497 */

	{ 0x800, 0xf35, 400 }, /* 4.0 dB intensity 251188.643151 */

	{ 0x800, 0xf1c, 500 }, /* 5.0 dB intensity 316227.766017 */

	{ 0x800, 0xf01, 600 }, /* 6.0 dB intensity 398107.170554 */

	{ 0x800, 0xee1, 700 }, /* 7.0 dB intensity 501187.233627 */

	{ 0x800, 0xebe, 800 }, /* 8.0 dB intensity 630957.344480 */

	{ 0x800, 0xe97, 900 }, /* 9.0 dB intensity 794328.234724 */

	{ 0x800, 0xe6c, 1000 }, /* 10.0 dB intensity 1000000.000000 */

As to how high or low you can go, at the moment the alpha code will let you go 100 steps in either direction. But, as I said, the volume will max out at row 100, +10dB. If you try to push a +20 boost on top of a -3dB player volume, you're still only going to hear +10dB. (In the same vein, pushing a -50 cut on a player volume of -30dB is going to result in silence!)

OK, cool, I think that matches my observed behavior. Personally, I don't mind the integer/curve issue, I think it's fine the way it is.

So what do you think about the pop issue? Do you think you know where the problem lies and can find a solution?

I have 2 possible avenues of attack for solving the pop issue.

First idea is to mute the mixer whenever we apply the eq. This is possibly a good idea anyway - the way that the player sets the eq values is to write the 20 sections straight to the DSP registers. I don't know how the dsp is supposed to handle this - whether it is supposed to read them all synchronously and apply them in one step or whether it just starts using the new values as they are written in...I suspect the 2nd, in which case the frequency of a section gets written before the dB/Q, which means that changing eqs could lead to transients, even without the extreme Q factor that we are using in the tone controls.

The second approach would be to apply 0 tone controls and then ramp the tone controls up to the set values.

Both of these have potential issues that I'm going to have to investigate.

The issue with the first is that when modifying an eq band completely unrelated to the tone controls, we'd be muting and uumuting the mixer. This'd happen a lot - every small frequency change would do this. It might or might not be audibly noticeable.

The issue with the second is that the tone controls would take some time to ramp. Admittedly, a very short time, but again - it'd happen every time an eq was adjusted.

So I'm between a rock and a hard place at the moment.

Oh, I've just seen something else that I can try first..

I think I know what the problem is.

I didn't stop the original eq from getting applied in the ioctl, I initialise the tone controls after this has happened. This is fine for bootup, but it means that setting a new eq has the same effect as the old "Off" problem.

Give me a couple of miuntes and I'll have a new binary.

Try this.

hijack246-volboost.zimage


volboost246.patch

Pop seems to have been fixed.

There is occasionally a slight bit of noise when switching between sources, but I don't think it's any more than there was before your changes were implemented. In other words, I think it's behaving exactly as desired.

I'm now working on balancing my inputs to the way I like them. At the moment, I think I've got a happy medium right here:

[hijack]
disable_bassboost_FM=1
volume_boost_FM=4
volume_boost_AM=-10

Since I don't have anything plugged into the Aux, I don't need an alteration to that input.

I'm still not certain about whether or not the disable_bassboost_FM is working or not. Anyone else want to take a stab at testing that?

Finally... :rolleyes:

Tony, are you testing on a MK2/MK2A ? Hardware revisions up to 6 (MK1 I'm guessing) don't appear to have a bass boost to start with, and the disable_bassboost_FM won't do anything.

Yes, this is on my mark 2. And I know that the FM bass got boosted in the original software because there were certain announcers on NPR that would make my car shake when they popped a "P". The thing is that I haven't listened to the tuner long enough with your code to have heard those announcers yet.

I haven't done any side-by-side comparison, but I'd venture to say that the bass boost isn't working. My FM seems to have a heck of a lot more bass than my MP3 but I also know that many FM stations are given a lot of bass at the source to sound more "full." I can however say that the volume boost/cuts seem to be working very well. However, I couldn't get the v246 patch to work right, I had to flash the binary instead. The patch is trying to create files that already exist and such, I don't think it was diff'ed from a clean Hijack source tree or something.

Anyway, thanks for all of your hard work, genixia... My initial test of this functionality seems to be going pretty well. Now I just need to dial in the right values... Any chance you could work this into the Hijack menu itself so we can adjust on the fly? Or is that not possible?

Err, the patch isn't creating any files. It is modifying two files that should already be present. I just checked the patch and it looks good. Maybe you weren't supplying the -p1 parameter?

cd kernel

ls

>hijack-246

>volboost246.patch

cd hijack-246

patch -p1 <../volboost246.patch

The bassboost has got me stumped. Just for kicks, try supplying 0 as a parameter. I could'a got the logic reversed! And I've been out for a coupla beeeeeeeeers, so I'm not going to check now.

It's highly unlikely that it'd be added to the hijack menu. The main reason is the extremely limited flash resources available. I virtually had to beg Mark for 12 bits of flash in total for storing bass and treble settings for both AC and DC modes! (Yes, each setting is stored in 3 bits...) *
Secondly, although this is a little awkward to configure, it should only need to be done once, and maybe tweaked a bit later if you decide you really wanted another +1 on the FM mode after all. ie, it shouldn't be a dynamic setting (unlike the bass or treble which can vary by song).

If Mark finds 100 bytes of flash stashed away somewhere then obviously there will quite a few candidates trying to use it in preference to config.ini values, but until then the flash will be reserved for the most deserving cases

* Well, maybe 'begging' is a bit strong. I asked for 24 bits and got 12....

I had the p1 parameter. The patch is *definitely* doing more than just modifying two files that "should already be present." At least the one you pointed me to is, at http://h0000e108b21e.ne.client2.attbi.com/genixia/empeg/volboost246.patch

Take a look at it, it's got no less than 20 files that it's trying to create, a whole bunch of stuff in include/asm-arm/arch, etc....

Aaargh. Sorry, shift reload helped. I kept viewing the cached version.

Yeah, ok I screwed up. The 'extra' files aren't really. The kernel source tree comes with a load of undefined symlinks, that get set by 'make dep'. So once you've built a kernel, there appears to be a whole load of new files compared to the same tree previously. My virgin 246 tree hasn't been built, but the volboost tree obviously has.

Try again now.

I gotcha. I'll give that patch a try tonight.

BTW I agree with your earlier points on why not to allow hijack-menu setting of the volume offsets. They should be "set it and forget it." Unfortunately, I still haven't found the right settings just yet so I have to keep dragging my Empeg in and out to find them.

I haven't done any side-by-side comparison, but I'd venture to say that the bass boost isn't working.

Funny, I'd come to the opposite conclusion last night.

True, FM stations always sound like their bass is boosted compared to MP3s, because they do over-EQ their signals before sending them out. But that's always been around, there's nothing unusual about that.

What I had noticed is that, over and above the bass-boosting the stations already did, the player would boost the bass in radio mode yet again, making it sound truly unnatural, especially when announcers were speaking.

Gen's 246 binary he released yesterday seems to have (for me) removed the extra bass boost as intended. However, I did not A/B test this feature by changing the INI file and running back and forth to my car. Someone should do this to be sure.

Okay then I officially change my position to "I have no idea if bass boost is working or not."

So, what's the verdict so far?

Is this ready for me to send to Mark for inclusion in Hijack as beta?

The main thing I need to know is that no previous functionality got broken and that the feature appears to work as advertised - which from the posts above, I take to be a yes. ( the bonus disable_bassboost_FM feature aside - if the jury's still out about that, then fine - that code is clean and simple and I can't see any reason why it shouldn't work and it is 'bonus' to the original feature request.)

So basically, that means that the boost/cut appears to work, and that changing volume/input or eq doesn't result in any new nasty noise artifacts...

??

Yeah, I think it's ready for prime time. Make absolutely sure there's no PrintK's left over in the code...

Yeah, I'm glad you spotted that one - I have my serial port car_rate=115200 in my config.ini, which is neccessary to see any debug messages when in DC mode (got added when I was chasing down the DC tone initialisation issue), but a side effect is that the stacatto effect doesn't happen either...

Thank you both your help in testing this code! Couldn't'a done it without you.

Mark may well optimise my code, so sanity checking the first Hijack build with it in is probably a good idea, although I think that he sprays his keyboard with bug-repellant...

>Is this ready for me to send to Mark for inclusion in Hijack as beta?

Gimme!

I'll have a look and probably stick it in.

Cheers

volboost246.patch

(No change since the previous post 13 up that had this link for those wondering.)

Now maybe someone (hint hint) would be willing to take a look at implementing volume adjustments together with L/R delay feature for a more accurate shift.

Then all we need is three quick presets (passenger, driver and OFF) with some button code method to cycle them and the feature is more than prime-time.

Bruno