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.