I thought of making a plotter for dB monitoring. dB seems to be a very complex thing, even if there are some formulas for that. But in the end there are lots of things that can vary. So far I've come up with this:
The plotter would constantly take sound samples from the microphone, like 500 ms of sound data.
For each chunk of 500 ms, it would add the square of each sample.
Take the logarithm of the sum. This value would be linearly relative to the dB value of the sound. Calibrate it using a real dB meter.
The used mic has to be calibrated, too. Even if the formula above would be right, the used mic would distort it, if not calibrated. But after testing and calibrating, I should have a rather useable dB plotter. It would continuously sample 500 ms, calculate the dB value, plot it, then sample the next 500 ms. Of course computing time would make the updating time higher than 500 ms, but that's no problem, as long as it plots something. Or does the sampling happen in some interrupt mode while the computer does the calculating?
]]>Im not sure it's as easy as to take the logarithm of the sum; the math looks something like: 20 log (P2/P1) where one of the P's is input power and the other is a reference power (1 × 10-12 W/m²).
]]>Yes, in my model the sum of the squares of the samples would equal P2/P1. But I'm not sure if it is like that. A microphone has a diaphragm that covers an area, which would be the m² part and the mic chord transfers an AC signal, which would be the W part. So in the end I just want to compute how many effect units a signal is, analysing only the wave form, that is amplitudes and frequencies and such. If it were a simple sine wave, the amplitude would be enough (or would it?). But when it is a very complex wave form, I thought summing the squares of the samples would be a measure of the effect of the wave.
]]>If you want the power of the signal, you want RMS (Root Mean Square). Take the square of each sample, sum them together, divide by number of samples and square-root. Transform into dB through logarithms and add or subtract a calibration bias. There.
]]>Great! Thanks, Tobias. I thought it would be something like that. The root thing I wouldn't have come up with. I'm still working on the sound recording thing. So far I have this code:
| 1 | ... |
| 2 | size = start_sound_input(44100, 16, 0); |
| 3 | buffer = new unsigned int(size); |
| 4 | textprintf_ex(screen, font, 10, 10, 0xffffff, 0, "%d %d", size, buffer); |
| 5 | alert("Start monitoring the mic", "", "", "Ok", NULL, -1, -1); |
| 6 | |
| 7 | do |
| 8 | { |
| 9 | if (read_sound_input(buffer) != 0) |
| 10 | { |
| 11 | clear_bitmap(screen); |
| 12 | p = buffer; |
| 13 | for (int i = 0; i < 1024; i++) |
| 14 | { |
| 15 | putpixel(screen, i, 384 - (*p) / 256, 0xffffff); |
| 16 | p++; |
| 17 | } |
| 18 | } |
| 19 | } |
| 20 | while (!key[KEY_ESC]); |
I guess I do something wrong, it crashes in the middle of the read_sound_input() call.
]]>If you wanted to simulate the classic VU meters, you could do 300ms averaging while applying a 10dB lag. I think that would be rather neat.
]]>I just turned to PortAudio and it works better than Allegro's sound recording. Cool. Next week I'll present my dB meter and as an extra bonus a guitar tuning program. Or something.
]]>