I'm thinking of competing in IASCA and as such am tuning heavily. Is there any way to make the Rio generate frequency tones? It'd be nice to turn the knob and vary the frequency from 20Hz to 20,000Hz. Ideally it'd go down to 10 Hz or so but 20 would be adeqaute.

Thanks in advance!

Create a "Test Audio" playlist using WAV files from your favorite PC application. I can generate tones, white/pink noise, frequency sweeps, whatever I need with either CoolEdit or SpectraLab.

Remember that the 2.0 software will play full WAV files, so you don't need to encode the tones into MP3 format. WAV doesn't have any lossy compression like MP3 does.

Oh, and remember to tag the Test Audio playlist as "Ignore As Child" so you don't get a 3500hz full-deflection sine wave shuffled in with your Britney Spears tunes.

Damn! Is there ever a time when you're not reading every forum?

I have several test tones and sweeps and so forth. I'm just curious if it could be done in software rather than by creating all those files and playlists. It'd be nice to have it adjustable in 1Hz increments just for the anal tweakability bragging rights of it.

To a non-programmer like me, it doesn't sound very hard in theory. In practice, how hard would it be?

In reply to:

---

so you don't get a 3500hz full-deflection sine wave shuffled in with your Britney Spears tunes.

---

I don't know, compared to Britney, some bottom-octave rib rattling tone might be less painful.

Seriously, I don't see any reason why you couldn't write an app that kills the player and talks to the audio hardware directly, once you've finished fiddling, the app calls the player then exits.

In fact, the first app I compiled for my empeg did just that, it beeped then quit. It's the sort of thing I'd love to write myself, but between work, running a student radio station and trying to pay attention to the g/f, I haven't got the time to do anything else.

unless they changed the rules recently, IASCA requires a cd player if i recall.

Got one. I just have the Empeg run into it as an Aux. You are right though, they won't let you compete with it instead of a cd player.

so basically your using the empegs as an equalizer? or are you running it from the cd players aux?

My guess is that he's using his empeg as the rest of us are - to listen to our music collections without carting a massive stack of CDs around. And that the CD player is typically only used for competition.

Well, there is this sample code for generating a DSP beep on the player...

#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <math.h>

#define EMPEG_DSP_MAGIC 'a'
#define EMPEG_DSP_BEEP _IOW(EMPEG_DSP_MAGIC, 0, int)

int main(int ac, char *av[])
{
int fd;
int pitch = 60;
int duration = 500;
int args[2];

fd = open("/dev/dsp", O_RDONLY);

if (ac == 3)
{
pitch = atoi(av[1]);
duration = atoi(av[2]);
}

if (fd < 0)
{
perror("Couldn't open dsp.\n");
return 1;
}

args[0] = pitch;
args[1] = duration;

if (ioctl(fd, EMPEG_DSP_BEEP, args) < 0)
perror("ioctl.\n");

usleep(duration * 1000 + 125000);

close(fd);

return 0;
}

I notice you can pass pitch and duration args to it...all you'd really need is an interface.

The existing beep interface only does midi notes from a predetermined scale (check arch/arm/special/empeg_audio.c in the kernel). Whilst useful for writing an app to play back musical tones (eg cellphone ringtones!), it's not (currently) that useful for doing eq work as it's too limited.

Patience. It is coming.

I still need to tweak a few things, but I currently have kernel that can produce any frequency 20Hz-17KHz on demand.

That's sweet. I can't wait to see that. It will be much easier to tune my system with using those. Are you planning on having it build into hijack or be a stand alone application run from hijack?

I currently have kernel that can produce any frequency 20Hz-17KHz on demand

see that picture to the left? pretend that shoe is your new kernel!

LOL.

I've written a couple of new ioctls so userland app can set the tones. I see this as being the way to go - anything really useful coming from this work will be too big to really live in the kernel. That being said, a simple hijack interface could probably be implemented, but I don't see much value in manually selecting/entering a single frequency at a time.

Much more valuable is a means to automagically step through a set of tones so that the response can be measured and noted down.

Even more valuable would be if I could also implement the microphone input, and automatically take peak measurements as well.

It would then be totally cool if a userland app could take the measurements, do some math with them and calculate an eq to flatten the system, and then write that to the empegs data partition.

As you can see, the dream lives in userland, but I am making kernel changes to support that.

At the moment I need to work through a couple of quirks. Specifically removing transient clicks at the start and end of the tone, and adding channel selection to the ioctls. Then I'll release a test kernel and some small command line test utils.

Even more valuable would be if I could also implement the microphone input, and automatically take peak measurements as well.

It would then be totally cool if a userland app could take the measurements, do some math with them and calculate an eq to flatten the system, and then write that to the empegs data partition.

As we've discussed before, this would only work to a point, because the mic input can't sample high frequencies. However, I would still like to see this become reality even if it could only do the corrections up to a certain frequency.

Ok, here it is. The first kernel with a built in sinewave generator.

READ and UNDERSTAND the IMPORTANT notes below


The sinewave generator has the ability to generate sine waves of any arbitary integer frequency in the range 20Hz <= f <=17000Hz, at arbitrary ( 0 - full scale) volumes. This could potentially damage amps and speakers if abused. Before you even consider using this, you should have confidence that your system is correctly set up; especially with regards to crossover setttings, and amp gain settings.

I TAKE NO RESPONSIBILITY FOR ANY DAMAGE RESULTING FROM THE USE OF THIS FEATURE.

That being said, I have made it default to a relatively safe volume level, 50% of full scale. But there are no artificial limits on the frequency or volume that can be selected. If you know that your speakers aren't protected against strong sub bass signals, then pumping a full scale 20Hz sine wave into them may have an undesirable effect. Play nicely.

The sine wave generator output goes through your EQ and (hence bass/treble) stage. This will allow you to determine what effect an EQ is having on your overall response.
Assuming that you are looking to test/tweak your car's EQ, you probably want to turn your bass and treble settings off whilst doing this. It's probably a good idea to start from a sane EQ too.
The sine will also be scaled by the main volume control. I'd strongly suggest that you don't have your player on full volume the first time you play with the sinewave generator.

The generator defaults to a 5 second duration. This can be over-ridden in config.ini. You do not have to wait for the duration of a sine before starting another sine, but it is advisable to do so. The generator uses an attack and decay filter to try and avoid transient glitches. If you do not wait for the duration, the decay filter doesn't get utilised - so you will probably hear glitches. Same caveat applies to using the Cancel/* buttons (or top button) to exit the generator early.

Play nicely with low frequencies. I'm still endeavouring to eliminate glitches completely, but you may experience some minor start glitching at frequencies < 80Hz.

You will see a warning when you first use the sine generator. It will recommend reading the Hijack FAQ. There is currently nothing relevant in the FAQ - for the moment it really means reading this post and the warnings/caveats within. When this gets accepted into Mark's hijack tree, I'll ask Loren to update the FAQ. This warning can be permanently disabled via config.ini.

Only use this when the player is in MP3 mode. All of the frequency, duration and attack/release DSP coefficients are based on the sampling rate, and are only coded for 44100Hz. The tuner uses a 38KHz sampling rate (at least for FM, not sure about AM..), and that will result in incorrect sine frequencies and durations. (It won't do anything nasty, but the values will be wrong).
I currently don't have any plans to make it work for 38KHz too. I'll probably make it autoswitch to player mode (unless adding 38KHz support is just as easy, or lots of people shout at me to do it.).

Anyway - config.ini options:

[hijack]
sine_volume=x ( 0 <= x <= 100, default 50)
sine_duration=y ( 100 <= y(ms) <= 11888, default 5000)
sine_warning=0 Disables warning.

Setting sine_duration=11889 will cause the sine generator to play a continuous sine wave. Only starting another sine wave or cancelling it manually will stop it. You may notice some glitches at the start and end of this, since there is no attack or decay filter in effect in this mode. (Limitation of DSP)

Please do not post about the sine_warning option anywhere. I don't want people to be able to disable the on-screen warning without having read the long warning. Reference this thread (or the eventual FAQ entry) by all means.


Controls - Remote needed. Numeric keys to enter frequency. Menu (CD on Kenwood remotes) starts the sine. Cancel (* on KW) will clear the current entry line. If the line is already empty, it will quit back to the hijack menu.

Anyway, enough talk. Kernel is v320.hijack+sinewave.mk2.zImage

Only Mk2/Mk2a at the moment. AFAIK, it should compile and work for Mk1 too, but as I don't have a Mk1 so I haven't bothered yet.

This kernel also supports generating sine waves from userland applications too. I have a few command line utilities that I've been using for testing - I need to clean them up and comment them before I release them.

Now hopefully I haven't scared everyone away. Have fun, and give me some feedback.

I must say, this is very nice. On my office system, it works very nicely. I had to use the empeg web interface v1.3 because i don't have a remote here. Now time to go buy a new battery for my remote for further testing

It would be nice to not have to use the remote at all, turn the knob to adjust the fq, and knob press, or down button to play the tone. top button to cancel the tone.

Agreed. If this enhancement could be made to the UI, that would really make testing a bit easier. I hope to use this to test my install - I seem to have a dead spot in the mid-bass range, likely from a crossover that needs adjustment.

Thanks for all the hard work! This is going to really help with tuning!

In reply to:

---

Please do not post about the sine_warning option anywhere. I don't want people to be able to disable the on-screen warning without having read the long warning. Reference this thread (or the eventual FAQ entry) by all means.

---

You probably want to include this request in the FAQ entry too.

1. Congrats on your promotion to Pooh-Bah status.

2. Can we get a patch?

3. Doesn't your "rejoice" function need parens?

if (++postcount >= 1600) rejoice();

Better? LOL. Those pesky semicolons are always catching me out too.

I'm generating a diff now.

The problem with the knob interface is that it's difficult to maintain integer granularity (important especially at low frequencies) whilst also allowing fast access to higher frequencies. It's going to be a pain turning the knob ~10000 clicks to get to 10KHz for instance.

One method would be to multiply the current frequency by a set amount for each click, ie

if (KNOB_RIGHT) frequency*=1.1
else if (KNOB_LEFT) frequency*=0.909


But that still removes granularity (marginally more than a full musical tone IIRC), and still requires 71 clicks to get from 20Hz to 17KHz.

Another thought is to try and time the clicks, which I will try at some time;

long last_knob_click;
if (KNOB_RIGHT){
if (jiffies - last_knob_click <= a_really_small_time) frequency += 900;
if (jiffies - last_knob_click <= a_not_as_small_time) frequency += 90;
if (jiffies - last_knob_click <= a_small_time) frequency +=9;
frequency +=1;
last_knob_click = jiffies;
}

... and similar for the left clicks, but with subtraction instead.

But I discoved the existing calculator function could easily be copied and bastardised to supply a numeric input, and used it. Actually it'd be cool to have both.

Diff against hijack v320 attached.

Is there any integer base log function? Or perhaps instead of using a constant increment, you can use a multiplier.

You could have something select between coarse and fine tuning. Or maybe even three levels.

The problem with math in kernel space is that the ARM doesn't do floating point. There is floating point emulation in the kernel that supports userland applications, but I'm not sure if it can be used in kernel space, and besides which, it is probably too slow to be desirable there.


I did add a fixed point library in this patch - the sinewave functionality uses it to calculate coefficients for the DSP. It could also be useful for re-implementing bass and treble properly. But although it should be faster than the floating point emulation, it's still slow compared to simple integer addition or mulitiplication. We can live with that if we're only doing a few such operations on an occasional basis, and the fixed point operation truly is necessary (as the DSP calculations are) but I'd still rather not use it if I can get acceptable results without.

Anyway, enough blurbing. Try this;

v320.hijack+sinwave_2.mk2.zImage

Patch attached. (Still against hijack v320)

very nice, much easier to use now

When the program starts, and you get rid of the warning and Frequency is at 0. If i turn the knob clockwise, it will count up from 1, 2, 3, etc... If I turn it the other way from zero, it goes straight to 20. The DSP can't handle frequencies lower than 17, right? so shouldn't the program start out at 17 right you turn the knob to counterclockwise, and 17000 when you turn it clockwise?

The tone generators range is 20-17000Hz according to the programming manual.

You've discovered a quirk that I've been playing with this afternoon, one that I decided was the cleanest way to leave the code.

The way that the numeric entry code works requires starting from 0. If we started from 20, then we wouldn't be able to directly enter any frequency starting with a 1, ie 123, 1234, 12345 Hz... For the same reason, the Cancel button needs to also clear to 0. Because of this, we cannot bound the value on the minimum end, so the code has to test that the value is > 20 when you press the Menu/CD/Knob.

But when we turn the knob left, we don't want to go below zero anyway since it doesn't make *any* sense. So we already have to do one compare operation per click anyway. But since we can't play anything below 20Hz, why go any lower when using the knob?

Turning the knob right is bounded at 17000 by a compare operation. I could have also put a minimum bound in to make it jump to 20Hz here too. But since these compares are happening for every click, I couldn't see any real benefit in doing so. Remember that the value is already sanity checked when we press Menu/CD/Knob...

I suppose I could look at making the value wrap around at each end though...having just re-read your post, I think that's sort what you were trying to suggest?

yes, i was kinda suggesting an easy way to go from one end to the other quickly. Its nice to know that your checking the number before playing it, i still haven't tried to play an unsupported fq. While i was waiting for my car to warm up, i was playing with the generator a bit. I would really like to see the click/pop removed somehow. Another feature i would like to see, would be a scripting engine? Some kind of syntax to allow us to upload a custom generator script, sweep through a bunch of fq, also being able to adjust how quickly it steps fq through the script

What the heck.

v320.hijack+sinewave_3.mk2.zImage will wrap the value from 17000 -> 20 and vice versa. It has some resistance built in to it, ie if you approach 17000 at a sensible rate it should stick there, with a faster knob turn required to get it to wrap.

Again, attached is a diff against Hijack v320

In reply to:

---

yes, i was kinda suggesting an easy way to go from one end to the other quickly.

---

Done...see above.

In reply to:

---

Its nice to know that your checking the number before playing it, i still haven't tried to play an unsupported fq.

---

Yeah, it's actually checked twice - the hijack interface calls the same functions that will be called from userland applications. Those functions check the values too. If anyone can ever get an unsupported frequency out of the tone generator I will be surprised

In reply to:

---

While i was waiting for my car to warm up, i was playing with the generator a bit. I would really like to see the click/pop removed somehow....also being able to adjust how quickly it steps fq through the script

---

There's the dilemma. Glitches are reduced/eliminated by the attack and decay filter. Currently they are both set to 20ms, which means that each transient should take ~100ms to complete. I can't understand how I'm still hearing *any* glitches in 'normal' complete sine mode. (ie, We know that perpetual sines or interupted sines are likely to glitch.) I've sanity checked and played with the filter settings multiple times. I'm still trying though.
The dilemma is that the minimum sine 'length' is in effect 2 transient lengths (ie 200ms) - the sine will take half the length ramping up, and the other half ramping down, ie it will be at full scale for ~0 time. This is what you would get at the moment if you requested 100ms 'duration'. Any duration less than that might cause clicks anyway.
But what that means is that if I (for example) increased the attack and decay times to 200ms, we'd need a 2 second length of time just for the transients.
That wouldn't be a huge issue for manual operation, but for userland-automated operation with a large set of frequencies, that could become an issue. Assuming that we could measure the response within 1 second, each sine would then have to be started a minimum of 3 seconds apart. A set of 100 frequencies would then take 5 minutes to complete.

But I'm still tweaking, feedback is helpful. What range of frequencies do you experience glitching at?

In reply to:

---

Another feature i would like to see, would be a scripting engine? Some kind of syntax to allow us to upload a custom generator script, sweep through a bunch of fq, also being able to adjust how quickly it steps fq through the script

---

Well, I'm not in the business of writing scripting languages - there's already plenty out there.
But the generator can be controlled from user applications. There's no reason why an application couldn't read a csv list of frequencies and durations and play them back...

The problem with math in kernel space is that the ARM doesn't do floating point. There is floating point emulation in the kernel that supports userland applications, but I'm not sure if it can be used in kernel space, and besides which, it is probably too slow to be desirable there.

Your suspicion is correct: NO FLOATING POINT WITHIN THE KERNEL. That applies to pretty much ANY decent kernel (Linux, *BSD, Solaris, ...). Though on Solaris one CAN do it if one manually saves/restores the FP state, dunno about the others.

The primary reason for such a ludicrous restriction, is that to be able to use floating point within a kernel requires that the kernel save/restore FP context whenever the kernel is entered/exited.. and the overhead of doing such is not nice to overall system performance.

Cheers

Has anyone noticed that the inexpensive Ratshack SPL meter (Cat No. 33-2050) has a microphone that is flat to 2K, and a provided calibration graph covering 2K to 20K? (Less than +/-4dB difference up to 10K.)
Or that it also has a line output?
Or that the DSP has a Quasi Peak Detector that can be programmed to listen to the Aux In? (Or to the EQ stage output?)

Or that this post has an attachment?

Okay, you've got our attention. Start talking to us about frequency response on that quasi peak-detector.

As good as the DSP and Aux In circuitry can handle.

So in theory, assuming that the Aux In circuitry isn't artifically limited, then that's 18KHz at the DSP.

Good enough? It's certainly better than having to sample the mic input and calculate the peak frequencies!

18k would of course be more than good enough. I just thought we couldn't do output and sampling at the same time, and we couldn't sample Aux at all. So how did this new information come about?

Indeed. This is intriguing!!!

Has anyone from empeg seen this thread yet?

Careful reading and understanding of the DSP programming guide...

We can't sample an input and play a different input at the same time. However the sinewave generator (tone generator in DSP speak, but I'm trying to avoid confusion with the tone (bass/treble) controls..) can be used in any input mode. It can be used in one of two internal modes.
One of those generates the sine at the input stage and effectively overwrites the current input. These sines are processed by the audio block (EQ, bass/treble, loudness, SAM, main volume) before output. This is the mode I would have liked to use, since we want to be able to test the EQ. The currently-released kernels in this thread use this mode.
However, the QPD description in the manual is a little ambiguous. It states that we can take peak measurements of the current input, but doesn't state which that is when the tone generator is active (ie raw input or the overwritten sine). Unfortunately, after having entered all the definitions and code needed to support the QPD in the kernel, I discovered that my suspicions were correct - it will take peak measurements of the sine wave when generated, and not of the current input.

The other mode for the generator is superposition mode, where the sine is superimposed at the output, after the EQ, bass/treble, loudness and volume processing. This is the mode that the current player beep code uses, and hence why the music doesn't stop when the player beeps.
At first glance this isn't useful to us. We ideally want the sinewaves to be processed by the EQ so that we can qualify our EQ corrections. And we also don't want the player music to mix with our sines. Sure, we could expect users to either pause or Quit the player when doing this, but that's not very user-friendly. Plus, for measurement purposes, we *want* an input (Mic input over Aux In), Can you say positive feedback?!
Then I realised that when the sinewave is used in superposition mode, it is added after the SAM (soft audio mute) block. That means by muting the player, we're still left with the sine wave. It makes the coding a bit more difficult, but works.

In case you hadn't noticed before, there are 2 peak detectors that can be individually set to monitor 2 different points in the processing chain. So we can measure the raw 'car audio dynamics' response to a known sinewave at one point, and by measuring the response after the EQ block we should be able to tell whether we're correcting for it.

See the diagram below.

<img src=&quot;http://empeg.comms.net/files/146948-empsine.png&quot;>

In the frequency domain;
C(f) = Car response
S(f) = signal.
EQ(f) = EQ response.

In normal use we hear C(f).EQ(f).S(f)
To hear S(f), we want C(f).EQ(f) = 1, so we are trying to get EQ(f)=1/C(f).
Actually, the value 1 isn't important. Since we like to change volumes, what is important is that it is a constant, and not dependant on f. So we want C(f).EQ(f)=K, or EQ(f)=K/C(f)

You can see that in non-superposition mode, we can only only measure S(f) and EQ(f).S(f). We have no way of measuring C(f)

But in superposition mode with SAM set, we are measuring C(f).S(f) at the input, and EQ(f).C(f).S(f) at the output of the EQ block.
The first measurement is of use to us - since we know S(f), it tells us about C(f). We could calculate EQ(f)=1/C(f) from this though. But the second value EQ(f).C(f).S(f) is also eminently useful. In the sinewave mode, S(f) is a constant. Therefore we're really measuring EQ(f).C(f). Do you remember that I said we wanted EQ(f).C(f) to be a constant?

We can not only calculate EQ(f) from the first measurement, we can test it from the second. As long as the second value is constant across the frequency range, the EQ is correct.

I'm not sure I understand everything you just said, but it sounds (a) like good news and (b) really really cool.

So what you're saying is that you think it's possible to, with some coding, really be able to use a Ratshack microphone hooked to the aux-in to calibrate your EQ?

Has anyone from empeg seen this thread yet?

No-one who understands the DSP, no. But I'll be waving it under the noses of the EQ boyz tomorrow morning. Automatic, or even well-informed manual, EQ would be a killer feature. Just how inexpensive is this inexpensive SPL meter?

Peter

Just how inexpensive is this inexpensive SPL meter?

When I was researching it for possible inclusion in my RTA work, I seem to recall it was under $50.00. There was a built-in calibration curve for it in SpectraLAB, so I was considering buying one.

My fear was that any microphone made by Radio Shack couldn't possibly have very good frequency response, so I chose to borrow a professional microphone from a friend which also had a built-in calibration curve in the software.

But if we can get some kind of proper auto-EQ working directly on the empeg itself, I'll buy one of those ratshack mics in a heartbeat. Especially if it uses the aux-in jacks... I've got those already run out into my storage compartment, so I wouldn't even need to open the dash to hook up the ratshack device.

Automatic, or even well-informed manual, EQ would be a killer feature.

You're telling me. I'd love to see this happen.

If this goes forward, there's a lot of things we need to keep in mind. Here's a few I can think of off the top of my head...

- The killer app would of course be fully automatic operation. Press a button, step out of the car for a few minutes, and it will EQ your system and write the results to one of the EQ slots on the scratch partition (since we've reverse-engineered that file format, right? ).

- A perfectly flat frequency response sounds awful. So if we actually can get to a fully automatic version, then we'd need to build in an optional "smiley" curve to it. Perhaps have more than one selectable smiley to cater to various tastes.

- Something I discovered when working with SpectraLAB might be worth mentioning: Standing waves where the front and rear speaker soundwaves overlap. Hard to explain in words, but basically what I'm saying is that there will be peaks and valleys in the sampled frequency response, and those peaks and valleys will change depending on where you move the microphone in the car (forward or back). So there might be some merit to having an automated system average two separate passes, once with the fader cranked forward, and once with the fader cranked backward. Of course, that wouldn't work in my car since I wired the subwoofer to the rear outputs, so it would have to be optional.

Something I discovered when working with SpectraLAB might be worth mentioning: Standing waves where the front and rear speaker soundwaves overlap. Hard to explain in words, but basically what I'm saying is that there will be peaks and valleys in the sampled frequency response, and those peaks and valleys will change depending on where you move the microphone in the car (forward or back). So there might be some merit to having an automated system average two separate passes, once with the fader cranked forward, and once with the fader cranked backward.

Unless you're talking about something different, this effect (nodes and antinodes at room modes) happens even with just two speakers, or even with just one. But it only happens with frequencies where one wave (a) fits in the car and (b) is quite large compared to the size of the human ear, so say 150-500Hz. All you can do about it is mount the SPL meter approximately where your head would be. Hopefully these effects aren't too severe, though; the inside of a car is a complex enough shape that I'd expect the room modes to have pretty low Q.

There might also be merit in averaging four (or two) runs, one for each occupant's head position.

Peter

http://www.radioshack.com/product.asp?catalog%5Fname=CTLG&category%5Fname=&product%5Fid=33%2D2050

$30

Tony, the digital SPL meter is about $50 but there is a non-digital one that is about $30 if I remember. I have one of the digital ones sitting here and I also have the line-in running to my center arm-rest.

This is kind of amazing... I remember this being brought up years ago but the reason given was always that the mic input had limited frequency range. I don't remember the line-in ever being throught of.

EDIT: Didn't see that genixia found the other cheaper SPL meter. About "stepping out of the car", wouldn't a human body in the car effect the response? If we can live with it (the tone), wouldn't it be better to stay in the car?

Ahh... the infamous BBS bug bit your posting when you edited.. to fix it, edit again, and re-enter the [[]image[]] tags from scratch..

Cheers

Aarrgh. Followed shortly by the infamous "Edit time expired" feature.

About "stepping out of the car", wouldn't a human body in the car effect the response? If we can live with it (the tone), wouldn't it be better to stay in the car?

Theoretically, probably. But bear in mind that background noise will affect the level that is read - to counter this, we probably want to measure at a level that wouldn't be pleasant to live with.

Also bear in mind that most modern cars have speaker placements designed to counter the human body's effect to start with. Bass frequencies don't get absorbed as much as treble frequencies, hence why the bass speakers are usually low in the door panels and why the tweeters are often high. (In '99+ VW Golfs front tweeters are on the inside of where the side mirrors sit, and rear tweeters are high on the door panel)

Bass is also non-directional so that's why Dolby Digital can send all of the bass to one sub (and why Bose systems can have the bass module hidden behind a sofa). I think that most music compression techniques (ala mp3s in the empeg) convert the bass to mono because it's hard to detect but will save on bit rate.

Anyway, that's a bit off topic. I didn't really think of the speaker placement that way - it makes sense.

I'm loving this thread, this topic is one of the very first posts I made "way back when" and it looks like it can happen. The other was cross-fading and that looks like it's on the distant horizon too. woohoo!

here's the correction curve that i've been using w/ the spl meter....

Click Here.

with my RTA experimentation from last year, i've found that the RS SPL Meter is very directional.. except for low frequencies, there is about a 5-10db difference between facing a speaker and facing away from it.

But bear in mind that background noise will affect the level that is read - to counter this, we probably want to measure at a level that wouldn't be pleasant to live with.

Since the perceived frequency response of a given set of amps/speakers tends to change with volume, ideally, you'd want to measure at a level that corresponds to your desired listening volume. But since we don't listen to pure sine waves for entertainment, it's possible that the optimum measurement volume would be different than the actual listening volume. Higher or lower, I don't know...

the digital SPL meter is about $50 but there is a non-digital one that is about $30 if I remember.

Do they use the same mic and have the same calibration curve?

I don't remember the line-in ever being throught of.

I'm sure it was thought of, but the problem was that you either (a) couldn't sample it, or (b) couldn't sample it while playing digital audio files (don't remember which). I think that what Genixia's talking about doing works around both of those by using a different method that we didn't think of before. I'm not sure I understand his diagrams completely, but it looks really promising.

But it only happens with frequencies where one wave (a) fits in the car and (b) is quite large compared to the size of the human ear, so say 150-500Hz.

I seem to recall seeing the nodes around those ranges, yes.

All you can do about it is mount the SPL meter approximately where your head would be.

But my head moves. And I saw the nodes on the spectrum graph moving pretty significantly when I was moving the microphone short distances (just a few inches).

There might also be merit in averaging four (or two) runs, one for each occupant's head position.

Or perhaps just averaging four runs, one each with the balance and fader cranked in each direction.

The ultimate, of course, would be to get a system where it took advantage of the four-way mode of the equalizer and auto-EQ'd the rears differently from the fronts.

But my head moves. And I saw the nodes on the spectrum graph moving pretty significantly when I was moving the microphone short distances (just a few inches).

Yes, you can't solve the problem perfectly. It's just the best you can do, that's all. Inside a perfect resonator there are positions where no increase in input power will result in perceived volume increase. Fortunately, car interiors are extremely imperfect resonators.

Or perhaps just averaging four runs, one each with the balance and fader cranked in each direction.

No, you said that before, and I disagreed for a reason . Changing balance and fader controls only simulates "moving the soundstage" if you ignore reflection effects, and node hunting is all about the reflection effects.

Peter

you ignore reflection effects, and node hunting is all about the reflection effects.

I think node hunting could easily be about direct front/rear speaker interaction, not just reflections.

Are you saying that altering the mic's position between the front and rear speakers would have no node issues in a zero-reflection (anechoic) chamber? I think it still would.

I would think that if you took two speakers, had them play the exact same music (i.e, like a front and rear speaker would), and moved the mic different distances between them, then you'd get nodes just as easily as you would get them from reflections. What's the difference between a reflection coming from a wall that's 2 meters away, or a fresh identical signal from a speaker that's 4 meters away? In fact, I'd think you'd get more prounounced nodes because the direct-from speaker signal would be more pure than a reflection of the signal.

[drool]Cool.... Auto calibrating stereo[/drool]

Of course I don't understand half of your post, but if you can make it work that would be awesome.

- A perfectly flat frequency response sounds awful. So if we actually can get to a fully automatic version, then we'd need to build in an optional "smiley" curve to it. Perhaps have more than one selectable smiley to cater to various tastes.

What about re-defining flat to include the newly calibrated offsets? Then when you pick your EQ settings, you're adding to the auto-calibrated settings. Of course, I don't know how you'd do this... maybe by hacking the voladj code? Maybe it's too much work and isn't really worth it.

What about re-defining flat to include the newly calibrated offsets?

That's more complicated than it sounds. Each band has certain characteristics that aren't linear, and you can't just apply an additional correction to them without changing their characteristics. Take a look at this to give you an idea of how the various parameters interact.

I just wanted to give this great thread a bump... any updates?

I'm still working on it, although my code immersion time this week has been limited. Efforts to completely eliminate clicks resulted in significantly messier code than I liked, so I decided to undertake a major restructuring, and implemented a state machine to track the generator state and prevent clicks. The good news is that it is pretty much click proof now. The bad news is that I broke the hijack interface in doing so, and need to clean that up.

When you do, I think this project might deserve it's own thread. I'm VERY excited about this.

Yeah, what he said.

This is a great tool dude. can't wait for the next version

I had really hoped to get the next version out by today, but it wasn't to be.
The DSP's tone generator doesn't appear to work *quite* as advertised, leading to much frustration on my part. Basically the idea of flip-flopping between the 2 tone generators to be able to play multiple tones without completely stopping it each time seems to have a flaw - the part of the DSP that is supposed to allow me to mute one of the generators doesn't appear to actually work for one of them (one mutes, one won't).
Aargh.
This could have been useful - it would have allowed doubling the attack/decay time without any penalty. It would have also allowed an easy way of interuppting a long sine with the next sine as soon as we have taken a measurement, something that would have made the auto stuff quicker.
So I'll probably revert a lot of my recent changes in favour of the old scheme of doing things, ie, one at a time. (After one more sanity check of my code).
But it will have to wait a while. I'm getting on a plane to Singapore in a few hours. I might be able to get online to check the BBS, but I won't be taking the empeg, so no coding. I'll be back a week Friday.

And I'd just like to add that Tokyo airport is very civilised.

Internet access @ $6/hour.
Smoking room.
Smoking area in restaurant.
Very clean and airy.

Now why can't US airports be the same?
Oh well, just one more flight to go...another 7 hours.

Wow! Cool to see so much progress being made. Any updates?

Bump from the dead!

hijack400-sinewave.zImage

Testing wanted. Should be speaker safe. I'd like to get this submitted to Mark ASAP before his tree grows out of sync, so the more people that hit this, the better.

genixia,

I just installed the hijack401-sinewave.zImage version from your site. It seems to work fine, except that I can't get the indefinite duration tones to work. I have this in /empeg/var/config.ini:

[hijack]
sine_volume=50
sine_duration=11889


Now how about programmable sweeps? Actually, it looks like there's an ioctl interface in your patch -- do you have any sort of sample app? I don't have a toolchain installed right now, unfortunately.

In any event, thanks for this tool. I am gutting a pair of Bose enclosures that came out of my car doors and installing new drivers, and your patch has already helped me decide to plug up the resonator ports when I install the new drivers.

Sorry for the delay in response...I'm not at home at the moment so I haven't been online this past week.

The continuous sines may be currently disabled. IIRC, I did that when I was having issues with getting both tone generators to play nicely together. I'll look at getting that back in next week when I get home.

Yes, there are ioctls for this, and I do have some simple test programs. When I get home I'll clean them up, comment them and release them.

Oh, can you do me a favour? Are you running a stock 16MB player without any memory upgrades?

If so, it would be really useful if you could look for the following line in a serial boot log;

"Memory: 15016k/16M available (980k code, 20k reserved, 364k data, 4k init)"

and report what the actual numbers are. Ta.

Sure:

Memory: 15000k/16M available (992k code, 20k reserved, 368k data, 4k init)


I actually posted the whole boot log (using your kernel) in another thread -- it's here if there's anything else useful in there.