Hi!

It's been six months since I received my Empeg, and WOW, I'm enjoying it everyday. I only used it a couple of times in the car using an FM transmitter to send signal to head unit because summer isn't arrived yet here in Quebec and I still have to install amps. But what an improvement from my previous CD chagner setup :-) Any song, any time. So impressive!

Now, here's my project: I would like to do a little converter that would send serial commands to the empeg (+ and -) to control volume,

I don't think it will be very hard to do: frequency (I plan to use speedometer input) to voltage converter (0-5VDC), using a PIC 16C877 analog input, processing and sending RS-232 commands using built-in interface. I plan to use a pot or two to adjust gain of the unit.

First question: In the developper area of riocar.org, the serial commands are listed:

> + Volume +
> - Volume -
> x Volume +
> z Volume -

Is it a known issue that the two last (x and z) are not working? (at least, on mine: MkIIa)

Second point: Whenever I send - and + commands (followed by enter), the display shows new volume setting (like if I was turning the knob).

My question: Is there any way to prevent the volulme pop-up from appearing when volume commands are received from the RS-232 interface. The way I plan my gadget, it will change volume every 5 or 10 km/h, so volume pop-up would be visible most of the time during city driving. My guess is that behavior is set in the player app, no?? If so, it won't be easy to change. Maybe a wish for next version ;-)

Would there be anyway to intercept signal going to /dev/dsp (that's audio device isn't it?) and change volume "after" player app instead? Is this how the voladj hack works? (Sorry if it's a dumb question, I don't understand very well linux sound management yet ;-) )

Any suggestion will be welcome, I'm still on the protoboard...



Not bad for a first post ;-)

Thanks guys

ElPerePaT
60G 040103838

That sounds really cool. I think many cars' speedo wire already is voltage variable, maybe this will make it easier?
As far as the speed settings I would rather have it inactive below 40mph or so and then kick in with adjustments every 10-15mph after that. This would avoid the "city driving" effect.
Chevy cars have this in most of their stereos and it seems to work nicely, anyone know how they do it?

In reply to:

---

Chevy cars have this in most of their stereos and it seems to work nicely, anyone know how they do it?

---

I had thought about SCV before, but I had not really thought about how they did it. It is on the stock chevy radios like you say, and since it just goes to the speakers from there, it has to be done in the stock head unit. My silverado doesnt have Onstar, so there was no special OBD wiring connected to my head unit. That means that the SCV has to have a signal in the factory wiring harness. Pretty handy to get to. On second thought, it could still be an OBD serial signal, but just in the same harness as the speakers and power. Need to do some research.

Looking at this discussion, something occurs to me:

Wouldn't it be TONS easier to implement speed-controlled volume as a HARDWARE line-level module that electronically attenuated two pairs of RCA outputs?

You would set the player's volume to the maximum top-speed volume, then adjust the bottom-level (low speed) attenuation via a knob on the hardware module.

Seems like this would be a lot easier than interfacing with the empeg, as you wouldn't need to build any serial-communication hardware, nor would you need to program a PIC with the serial codes. Okay, not as COOL as doing an empeg interface, but it would be more universal, too.

Once the GPS project is complete, I imagine this would be quite easy. (ie. get your speed from the GPS data)

The analog idea is a good one. That's a way I had not considered. I've seen a few circuits (something called variable gain pre-amp or automatic controlled gain preamp) The noise and frequency response of that device worry me though.
An other difficulty is to create the -15V (or -12V would be enough) used by the op-amps (at least, for the one I've looked at so far). Do you know an easy way of creating a +12V/-12V in a car. I'll read on and keep you informed, as it is a long time wish for some users.

Best regards

Elperepat

I think this is a great idea!

Most cars use a pulsed variable frequency signal from the transmission to drive the engine ECM and speedo. Maybe that could be connected to the mic input? No serious hardware required, if any. Maybe just a resistor network to divide the signal down and a transformer for isolation. Sounds like a relatively easy thing to build into the kernel/Hijack. Since different makes/models have different calibrations for their speedo's, there could be some parms in the config.ini so it could easily be customized. And if it's done in the kernel, I don't think the volume bar would pop-up.

Cheers,
Phil

Chevy cars have this in most of their stereos and it seems to work nicely, anyone know how they do it?
Ford has this as well, at least in some models since 1999, they call it AutomaticVolumeControl and worked very well. I'm not sure how it works most likely a mic input that measures ambient noise, as there is a small grill on the dash of the vehicle about the size of a mic either that or it's the temp sensor.
You actively set the AVC amount thru the stereo from values of 1-9? this setting determines how aggressive, it seems, the volume is raised compared to speed or whatever determines the volume increase.
The system works very well, better at low AVC settings as you don't notice the increase in volume as much as higher settings.

I would rather have it inactive below 40mph or so and then kick in with adjustments every 10-15mph after that. This would avoid the "city driving" effect.

When set right via the stereo control you don't notice any pumping or the increase/decrease just that it's NOT blaring at you when you slow to stop or it's NOT too weak to be heard at highway speeds.
I like the it alot and it would be a great feature on the Empeg if someone who is profecient at such things since I'm not.

Prior to the empeg, I had a JVC Kameleon headunit that could do this. They call it the "Audio Cruise Mode" and the manual describes it as monitoring the alternator current to detect the speed. It also lets you change the sensitivity and set the "idle" speed.

It was pretty handy, even for a fairly quiet car.

The moral of the story is: there's no crazy factory radio voodoo or audio sampling behind this technology. It can be accomplished by monitoring electrical signals.

monitoring the alternator current to detect the speed

I don't think this could work.

All it could do is adjust volume proportional to engine RPM, not vehicle speed. So what happens when you go up through the gears? It gets louder, then quieter, then louder, then quieter, etc.?

And since the alternator output, once you reach threshold RPM (just above idle for most cars) remains a function of electrical load required by electrical accessories currently in operation, I am not sure just what the JVC would have been monitoring.

Might be interesting to find out what was really going on with that unit.

tanstaafl.

Yes, I believe that it did operate based on RPM and not MPH. I think that it resolved the gear shifting situation by essentially only going into "louder mode" when your RPM reached a point that was presumably overdrive (it seems to essentially be designed to counter highway road noise) or getting there.

I think that it only made one (or possibly a very small number) increment to the volume, it didn't scale it.

The car that this was in generally stayed low on RPM, so this feature wasn't hugely useful. Generally I had it set on its lowest modifier setting so that the difference wasn't huge.

Incidentally, I still have the unit and I'll look in the manual to see if I'm missing something about its functionality.

I have my doubts about this. If you're in overdrive, presumedly the engine rpms should be low..........

Calvin

Just wondering if this is a dead project now? If I had enough brain cells I could probably help, instead I have to rely on other people's genius.

Naah...it's just in biostasis. It really needs either GPS support or OBD2 support to mature before it can be done.

I just got finished installing an aftermarket Cruise Control on my new Honda Insight, and after a bunch of reading on the 'net, I can tell you there are two main ways people use to gather speed info from a car:

1) Alternator noise, as listed above... note that this doesn't work with my car since it's a hybrid so it's electrical system is.... nonstandard, to say the least.

2) tap into the spedometer cable. These days most spedo's are apparently electronic and work in some number of pulses (voltage spikes) per mile... I had to set my cruisecontrol to 4000 pulses per mile, with 8000 apparently being another common setting. This would seem to me to be the easiest way to add speed-based volume control to your system: tie the pulsing voltage of your spedo cable to some input on the serial port (CD maybe?) .

Just a pair of pennies that I hope you find helpful...

--pj

This morning as I was driving to work thinking about speed sensors, I realized that speed-controlled volume would be a very Bad Thing.

Reason:

When I am on a well-paved road, such as the stretch of highway 20 between my home and work, the car is very quiet, even at very high speeds.

When I am on a poorly-paved road, such as the stretch of interstate 80 to the west of Truckee, the road noise is deafening, regardless of speed.

So I would much rather see a volume control based on an exterior mic mounted under the car measuring road noise.

I'd love to implement a speed sensor for other reasons, but not for volume control.

Speed dependent volume does/will not eliminate the need to adjust the volume. You just don't need to mess with it quite as often. There are far too many uncontrolled variables affecting the perceived "signal to noise ratio" to expect to totally eliminate the need to adjust the volume. (Your passenger complains...!)

Still SDV can be a nice improvement over nothing at all, kind of in the same catagory as "VolAdj" incorporated in Hijack.

Lynn

Good points.

Still, if given the choice between speed-controlled volume and ambient-road-noise-controlled volume, I think the latter would be more useful.

hmm... I´ve read somewhere that you can terminate a percentage of noise by recording it and play it back just phase inverted. That way the soundwaves eliminate eachother. Wouldnt that be kinda cool to have as a feature in the empeg. Just hook up a mic and phaseinvert the signal and play it over the tune running in the empeg.

I´m not sure this works in reality, if what i read just was a undergoing research or what. I dont remember. Maybe someone else has some input for this.

If it is as i say there wouldnt be that much trouble implementing it to the empeg.

You are referring to "active cancellation" and it's a very tricky business with very limited application. Unfortunately, it would not work with the empeg in the car because the road noise emanates from all around instead of just one point, and also the mic input can't sample high enough frequencies to get all of the noise.

as you said it, it seems logical enough. (argumenting against myself) And how would you separate the cancelation betwwn the noise and "what you want to hear". Allthough... its kinda neat in its simplicity in theory that is.

Yes, active cancellation is simple in theory, hard to implement in practice.

In practice, it only works when either:

a) The noise is emanating from a specific "point" such as a loud machine of some kind, and you can mount a speaker very close to the loud machine and point the speaker exactly at the listener. And remember that the speaker must be able to match the timbre and volume of the loud machine to be able to do any good. For example, to quiet the sound of a diesel engine, you'd have to have PA-system size speakers and huge amounts of amplification.

b) The sensing microphone and the speaker can be very very close to the listener's ears. They have successfully implemented this in noise-cancelling headphones for years, but it's only useful because it's all self-contained in the headphones and it's right next to the ears.

I don't know of any other examples that work, does anyone have any other examples of active cancellation?

The problem with trying to do it in the cabin with car speakers is that you would have to do it with multiple microphones and then tune it for only one passenger's ears and it still wouldn't be perfect. And as soon as someone else got in the car, the noise would be worse for their seating position, you couldn't have a "universal" setting for multiple passengers.

So is this now doable within GPSapp? Despite Tony's reservations about road noise I think speed controlled volume is a good idea. My girlfriend has this in her new mini and it works brilliantly.

Although the ideal would be to monitor noise levels this looks very easy to do with a blend of hijack, voladj and gpsapp. Presumably gpsapp has a real time view of vehicle speed - this could then be applied to the voladj algorithm?

The ambient noise version might be possible with a cheap external microphone on the vehicle (maybe a dry corner of the engine bay, but definitely away from the in car speakers to avoid strange feedback effects). A very rough and ready average volume indication performed on the empeg could then be used to drive voladj instead...

Not using voladj - voladj is effectively a form of compression, compressing the dynamic range of a piece of music so that quiet passages appear louder and vice versa.

But in theory, GPSapp could talk to hijacks mixer IOCTLs to adjust the volume.
A couple of issues to consider though;
GPSapp doesn't currently do anything whilst it is not active. So you'd have to have GPSapp visible in order for speed adjusment to work. I think that Jan is planning to address this somehow.
How to track/account for intentional player volume changes? One approach would be for GPSapp to try and track what the player is setting the volume too and to modify it from there based upon current speed. The other approach would be for GPSapp to simply read and modify the volume every time the speed changes past some boundary. Both options have their merits and pitfalls. I'd suggest the 2nd is probably easier to deal with.
Another issue is to ensure that the system had some hysterysis built in - we wouldn't want the volume oscillating because we're cruising around a boundary point.
And finally, does anyone have any idea how much adjustment would be desirable? And where would you start? 0.5dB/10mph above 30mph? 1dB/10mph?

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?

If gpsapp is not installed, this can just default to 1. Increase this factor to 1.1 to increase whatever the current listening volume is by 10%. I thought this was the kind of approach taken by voladj, which is why I was thinking along those lines... I know empeg is not brilliant at floating point calculations, but an integer based approximation would probably suffice.

Naturally, this just shifts some of the hard work from gpsapp to hijack, but the functionality might sit there more neatly (since current volume is already available), and perhaps be reusable for other applications too. So, if volume adjustment via ambient noise or OBDII takes off, they could both use the same hijack feature, rather than writing the same code 3 times on separate projects.

As for the specifics of the volume adjustment, I'm guessing this will be largely trial and error, and will vary depending on personal preference, the vehicle & level of sound insulation, tyres fitted etc. Maybe just building in a whole pile of configurable parameters, perhaps with a couple of 'get you started' default settings is the way to go?

The thing is, my JVC headunit also does the volume adjustments. And the difference is that it really look at the car's speed, but the rpm of the engine. My car makes most noise as I am accelerating or going uphill, and gpsapp won't know how hard the engine is working in such situations.

Tire/road noise on a highway isn't that much. Besides you typically maintain the same speed for a while on a highway and adjusting the volume by hand really isn't that hard. Most noise is introduced when someone opens a window which neither speed nor rpm based volume adjustment will ever figure out.

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.

Fair enough, you've convinced me. My suggestions come from a high level, dumb ass user perspective, rather than any position of detailed understanding of player & kernel operation!

This volume adjustment lark is starting to sound a lot more complicated than one might think.... Still, I think it's worth at least making the volume adjustment code portable & generic so it could be reused in other projects if necessary.

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'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...

Despite Tony's reservations about road noise I think speed controlled volume is a good idea.

Keep in mind that my reservations were about active cancellation, which is a different animal than speed-controlled volume.

The idea of having GPSapp determine the speed and do speed controlled volume is an interesting one.

edit: okay, I also talked about road noise...

Alternatively, GPSapp could monitor acceleration/deceleration and use that to tweak volume rather than just a snapshot of current vehicle speed.

I can envisage some scary calculus & differentiation algorithms arising from this.... shudder...

Oh, and this isn't my idea; I just thought I'd prod the conversation on a little for selfish reasons (grin)....

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.