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?