How about using gpsapp to send some kind of scaling factor to hijack, and then letting hijack apply this scale to the current user selected volume to determine the appropriate speaker volume?


Can't be *easily* done. The voladj code works with the individual samples, and is not the easiest code to understand. The mixer volume code is based on a fixed size array of discrete values, so we'd have to calculate which row was now needed. A bit messy.

But the real reason why this is not such a good idea is that hijack already has a volume kludge in it to boost/cut volume based upon current source to enable people to balance FM/AM/Aux/player levels, and it'd be easy to break this code should the 2 features not interact correctly. The volboost code was designed to be transparent to the player (and hence other userland applications). It achieves this by intercepting the player volume adjustment call and modifying it based upon the users volboost_ settings. It also lies to the player when it is asked what the current volume is...In order to do this, it has to track the current boost amount, and also what the player thinks the volume is. This would make any kernel-based solution to this more complex.

The other point is that there isn't any IOCTL suitable for doing it that way. The voladj code is purely in the kernel - no parameters ever need to be passed to/from userland - the parameters are in config.ini and the setting is adjusted from within hijack itself. What you are suggesting would require that GPSapp talks to the kernel and apply a scaling factor, which would require a new IOCTL, again, more complexity.

The idea that GPSapp would use the existing volume IOCTLs would work well for this functionality. The volboost code would continue to work transparently in the kernel, and GPSapp would read/set the volume much the same as the player application does. The only complexity is in the algorithms required to calculate when to step the volume up or down.