Quote:
Originally Posted by liteon
the 'n' parameter is the number of elements you've accumulated.
if you define a max window length 'n_max' (n_max = miliseconds*samplerate/1000) then you should reset 'sum' and any possible iterators to 0 when the iterator meats n_max.
but when calling rms = ....
'n' should be always equal to the number of accumulated elements (n = iterator value) and not 'n_max'  well unless you set rms calculation to be at iterator == n_max.

I might not get the wording, but from how I understood it have to disagree. [EDIT]
When you want RMS in a compressor (or any other realtime stream) you don't to reset the RMS nor the sum each time you processed one window. What you want is a so called running sum, that gives you the RMS at any given sample position in the stream.
So basically you have the usual formula:
rms = sqrt(sum/win_len);
with 'sum' being the sum of the square of the 'win_len' last samples (all samples before sample with index 0 are assumed to be 0.0).
So all you then need to do is keep a sum of the last 'win_len' samples squared in 'sum' and then apply the above formula to get the RMS.
An optimized way of keeping track of 'sum' would be to keep an array with the last 'win_len' samples squared and everytime you add a new squared sample to sum you also remove the square sampled value from 'win_len1' from the array and add the current squared sample value, like this:
Code:
sum = a[n];
a[n] = cur_spl^2;
sum += a[n];
rms = sqrt(sum/win_len);
n=(n+1)%win_len;
Of course there are approximations (RCfilter) that are WAY more faster.
EDIT: Ah liteon, I think I got it now, you'd only calculate RMS per block, which would be OK for a meter that doesn't have high update frequencies and the rest only makes sense if you calculate RMS for statistics in which the window size will be the length of the audio data you analyze.