What DSP code is this ASM rms calc?

[nix]

Hiya 8D
I have been intensively using Bootsy's fast RMS asm code.
I was wondering if anyone would mind writing it in DSP for me?
Here's the code->

fs3081 Bootsy fast rms.fsm

(686 Bytes) Downloaded 830 times

Cheers, I looked at the Wiki,
but the DSP implementation might help me understand.
It's a wonderful algo-
ta Bootsy!

[martinvicanek]

Code: Select all

streamin in;
streamin c;
streamout out;

float rms;
rms = rms + c*(in*in - rms);
out = sqrt(rms);

You may get denormals (in both the ASM and DSP) if you feed it with synthetisised audio. Easy fix:

Code: Select all

streamin in;
streamin c;
streamout out;

float rms;
float denorm=1e-11;
rms = rms + c*(in*in - rms) + denorm - denorm;
out = sqrt(rms);

[tulamide]

This is interesting for another reason.

Martin, as a guru of DSP, what do you think how long will it take until this code outputs meaningful values? I compare it to the origin of rms, which is taking the root mean square of the whole audio. On old consoles and early computer measurings of realtime audio, they measured in windows of certain sizes. This code seems to not have any window size, so I wonder about it - thus the question.

[nix]

Thanks so much Martin!
will test it.
'c' is the window Tula, you need the original samples conversion in the first upload too
2205 samples @ 44.1k is accurate enough. longer is better precision, and shorter is not delayed as much
Cheers folk!

[martinvicanek]

how long will it take until this code outputs meaningful values? [...] This code seems to not have any window size

The code contains a so-called leaky integrator for the squared signal. You can think of it as a sliding average with an asymmetric (exponential) window. As Nix points out, the c parameter (or rather its inverse) denotes the effective window size.

To your question: Yes, there will be an exponentially decaying transient at the beginning. After a few window lengths the transient is gone and you will get "meaningful" readings.

A rectangular sliding window would require only one window length to reach steady state. A sliding window consumes a bit more CPU than a leaky integrator.

[nix]

So the square root makes it more accurate maybe?
-also, could we rectify instead of- in*in
then we wouldn't need the square root?

ta Martin for helping with the integrator concept

[martinvicanek]

could we rectify instead of- in*in
then we wouldn't need the square root?

Sure, but then it wouldnt be exactly RMS. In many cases it does not make a difference, though, and you can get away with a rectifier.

[tulamide]

Ah, thank you both! I understand the code better now, esp. the difference between rectangular window and leaky integrator. I come to the conclusion that I often use techniques in Ruby (my peak meter works with rectangular window), that I don't know the names of (or even think I came up with it first ).