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