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.