Just as a matter of interest, how difficult is it to add new IOCTL calls? Are these defined within Hijack for custom applications to use, or are they already defined within the kernel for the player application too?

I don't know...I've never added any..but it's certainly possible for some of the hackers here.

I'm just wondering what would happen if two competing applications are attempting to adjust the volume (ie. the player app when the volume knob moves, and volume adjustment code as some external variable changes). Would both app's be using the same IOCTL calls? I guess if GPSapp is just modifying current volume when vehicle speed changes more than a given amount the two apps would still work alongside okay...

That would be the beauty of doing it in userland using the same IOCTLs, and having GPSapp simply stepping the volume upon speed changes vs having GPSapp try to track the current volume or doing it in the kernel.

Let's say that you've just got in the car, and you set the volume quite loud, eg -10dB whilst motionless. The player volume shows -10dB etc. As you accelerate, GPSapp steps up the volume until eg when you're at 65mph, the volume is now at -6dB. (Assuming 1dB/10mph starting at 30mph). And this is working well. Now you get a mild headache, or you want to hold a conversation, or for whatever reason you want to turn the volume down a bit. When you first turn the knob, the player will display that you were at -6dB. Let's say you turn it down to -15dB, which is a comfortable conversational level at 65mph. Now when you slow down to a stop, GPSapp would step the volume down by the same amount that it stepped it up earlier, ie 4 steps, so you'd be at -19dB. (And the player would display that now were you to readjust the volume again.)

So in theory, your 'base' listening level adjustment of -9dB would still be intact.

In practice, there's another curveball that gets thrown at us. I mentioned earlier that the volume settings are a fixed size array of discrete entries. It so happens that the dB step between entries isn't actually a fixed amount. At extremely low levels the step is 2-3dB. For most of the useful volume range, the step is 0.5dB, but if you don't have the 'limit volume to 0dB' setting flagged in Emplode, the steps between 0dB and +10dB are 1dB. In practice, this shouldn't matter too much. It does mean that talking about '1dB/10mph' is meaningless. We'd be better off talking about '2 steps/10mph', or 'step/X mph'. We just have to accept that the step size isn't consistent across the whole volume range, and I'm sure that the functionality will still work well enough for it to be useful. (This affects the volboost code as well - and people using that find that it works well enough to be useful.)

So in practice your 'base' listening level adjustment of -X 'volume steps' would still be intact after a speed change.

Now if you changed volume whilst dramatically changing speed then that previous statement is invalid. But the whole point of this feature would be to make that irrelevant anyway - set the volume to a good level for your current speed, and it'll adjust itself.

Yep, I'm with all of that - it does seem like a nice clean algorithm to me. What would be nice is to make the various parameters configurable so everyone can tweak the adjustment to suit their own preferences.

I presume there's an IOCTL call for reading config.ini already from a user app? If so the config stuff could go in there (I seem to recall other userland apps using this approach). I haven't checked whether GPSapp already has support for configuration settings - worst case scenario would be a few additional command line switches to tweak the volume adjustment.

If I understand your explanation correctly, then the need for hysteresis is removed too... Nice!

If I understand your explanation correctly, then the need for hysteresis is removed too... Nice!


That got simplified out in the discussion, but would still a good idea, and would be handled by the GPSapp algorithm... Following on from the hypothetical scenario earlier, the transitions should occur:

mph.
(0) - set 'base' volume to -10dB
30 +1 step
40 +1 step
50 +1 step
60 +1 step
(65) 'base' volume changed.
50 -1 step
40 -1 step
30 -1 step
20 -1 step.

This would allow us to cruise within a 10mph band without the volume constantly changing.

Hmmm... this sounds great to me, i've got some reservations about how well it's going to work...

Does the player remember what level it set the volume at, or does it read it back from the kernel/DSP? If you try and change it through the player, it'll bring up the volume display, which would cause problems. (Or... There's a serial command to change the volume. Does it bring up the volume display?)

The seccond problem is GPS lag... The speed is farily acurate, but I don't remember it being too in sync. It seems the main reason you don't notice the volume changing is that it's done exactly as the road noise decreases. I'm playing with the Tahoe with SCV this week again, so perhaps I'll try try and pay more attention to it. From what I've noticed, I keep it on the highest compensation setting, and rarely have to adjust the volume. What we really need is someone to put the HU on a bench with an waveform generator and see how it's responding to the increased speed. (linear, exponential...)

Matthew

Does the player remember what level it set the volume at, or does it read it back from the kernel/DSP? If you try and change it through the player, it'll bring up the volume display, which would cause problems.

A proper volume adjustment system on the empeg would not mess with the ACTUAL VOLUME SETTING, it would modify the digital bitstream of the music, independently of the volume setting. That's what the current voladj compressor does.

A speed-controlled volume system would attenuate the digital bitstream's volume level when there is no ambient noise, then gradually lessen the attenuation as the ambient noise got louder. Finally, at full freeway speeds, there would be no attenuation and your player would be playing at the same volume as displayed by the volume knob indicator.

In this way, the volume knob would be setting your "desired apparrent volume" which is variable depending on your mood, and the speed-controlled-volume would be adjusting THAT to the background noise.

Does the player remember what level it set the volume at, or does it read it back from the kernel/DSP?

Not 100% sure. The ioctls allow the volume to be read. I *believe* that the player sets the volume, and then reads it back for the display, and I know that the player remembers the volume when shutting down so that it boots at the same level next time. But I don't believe that the player particularly cares about what the volume is otherwise.


If you try and change it through the player, it'll bring up the volume display, which would cause problems. (Or... There's a serial command to change the volume. Does it bring up the volume display?)


No if I understand you correctly, you're missing the point. GPSapp would use the same ioctls that exist in the *kernel* that the player uses, not use the player itself to make the changes.

Ach no. Funking around with the bitstream is way overkill for this purpose - the adjustment is basically static in sample terms, and the DSP has a perfectly good built-in volume control. We're talking about adjustments once per second max (limited by GPS data rate), and modifying samples at a 44.1KHz sample rate in order to achieve this is crazy.

Using the volume ioctls as I described above would mean that the display would always show the actual volume (ignoring volboost factors of course). But does that *really* matter?

In reply to:

---

A proper volume adjustment system on the empeg would not mess with the ACTUAL VOLUME SETTING, it would modify the digital bitstream of the music, independently of the volume setting.

---

Au contraire, Tony. adding/subtracting integers to the volume setting is exactly the way to do it, if you don't want to introduce another set of rounding errors to the audio data, and if you need to be able to boost the level as well as cut without risking clipping (or worse) - which I expect is what's desired, as it's natural to have the player's base setting correspond to "stationary, engine off".

My take on this is that it would be nice to have a volume boost/cut ioctl in Hijack that can be used by GPS-based or microphone-based noise compensation. (I'm using the term "noise compensation" to describe what we're discussing, to distinguish it from (active) "noise cancellation"). Like you, I don't think that changes in the volume level should be visible to the player. If I set volume to -20dB in the carpark, then get up to 70mph (honest!) on the motorway, I think it should still show -20dB. Your phrase, "desired apparrent volume", makes a lot of sense to me.

I don't know much about ioctls, but I think it should be possible to write the device so that when it is closed (either intentionally or by the noise compensator crashing), it can reset the interposed gain to zero. This is one reason why I favour a volume boost over a cut - if the compensator crashes, I'd rather get a drop in level than a deafening!

One thing that would be really cool but I lack the necessary skill to do is to listen to microphone input in the car and cross-correlate this with the player's output, in order to keep a ratio of player sound to non-player sound roughly constant. You'd only be comparing the low frequencies, of course, due to the mic input's limitations, but road noise is mostly at the low frequencies anyway. Having the ioctl support for this is an important first step.

I reckon the overall volume level should be changed. I know in my car I change the volume about 10dB from stopped to highway speeds (and that's with the windows up). Hmmm, although I guess 12dB is only two bits of accuracy in the sample magnitudes. But it would mean that you're losing this accuracy when you need it most (i.e. the ambient noise is lowest).

I was thinking that any volume changes ought to be visible to the user. If you initially had it at -20dB, your speed controlled compensation is changing it to -15dB, then you really do only have 15dB of room to play with. 0dB is still the normal output from the player with no attenuation. So I reckon that the user should see -15dB in this case, because it's the only thing that makes sense.

On the other hand, if the volume control showed positive dBs then it would make more sense to leave it alone. For instance, if the volume showed 10dB, which meant that the music was ten times more powerful than the ambient noise, then that should be the same no matter what any speed based compensation was doing to the actual gain. (Even if the system was unable to provide that level, because it was already maxed out.)

Also, if you did it this way then all the speed compensation needs to do is have some sort of curve (customisable of course!) relating speed to ambient noise. Plus, you could use the input from the microphone as a factor in calculating ambient noise if you wanted. All of this has the advantage that the compensation doesn't need to store any state in the flash, so it won't get confused when (for instance) you turn the empeg off while travelling at speed, and then turn it on again when you're stopped.

(I realise we could use the existing volume in this way, like Tony was suggesting, but like I said before, to me it doesn't make sense in the real world (what does -20dB mean in that case?).)

My goal would be to have something like this, plus have the ambient noise (calculated or measured, or a combination of both) feed into voladj, so that you didn't get so much compression happening when you were stopped.

Actually, I'm planning to do a bit more work on voladj soon (after a loooong time!), so while I'm at it I might see if I can put in some infrastructure to allow changing the parameters based on some external parameter. Then it will be all ready to be plugged in when someone has the speed data available.

Richard.

So have there been any breakthroughs recently on this topic?
I'm too dumb/time limited to figure this kind of stuff out but I eagerly await any results.