Calculation of Leq

[buv]

Hei Helmut,

while looking for a good framework for noise measurement I found your project, which impresses me deeply!

On Tuesday my Teensy 4.0 and the Tindie ICS-43434 board arrived and the fun part started. I had a closer look at the loop function of the DNMS software and I perceive its function as follows:

• if rms data is available, read and accumulate rms value and number of read audio buffers
• if 35ms have passed, calculate average rms and add it to overall leq value

The number of reads of the audio buffer (128 samples resulting in approximately 2.9ms @ 44.1kHz) during the 35ms varies between 12 and 13. A measurement loop with 12 audio buffer reads should be weighted differently compared to one with 13 reads. However, the calculation of the overal leq value does not distinguish between the two cases.

The overall effect of this is surely not terribly significant, but what about controlling the measurement loop by the number of audio buffers read rather than by milliseconds? If one asked for 12 buffers reads, that would result in 34.8ms for the measurement loop. Is this deviation from the initial 35ms problematic?

Greetings, Burkhard

[hbitter]

Hi Burkhard,

could you explain a bit more what you me mean with "A measurement loop with 12 audio buffer reads should be weighted differently compared to one with 13 reads"?

Is this deviation from the initial 35ms problematic? I don't thing that it would be problematic in any way.

you are right the measurement loop could have been over the number of blocks of 128 samples. I started with the time and didn't changed it so far. I don't think it makes a difference though. Regards, Helmut

[buv]

Hei Helmut,

there is a jitter in the measurement loop. When entering the measurement loop, the rms sum is divided by mean_count_A. This variable is either 12 or 13, depending on how the interval of the measurement loop is positioned to the audio buffer readout. So the 35ms-average consists either of 12x128 samples or 13x128 samples. A 13-buffer average should have a higher weight compared to a 12-buffer average. This distinction gets lost, since all averages are unweightedly summed up.

My suggestion would be to exchange line 209

if (leq_loop > leq_single_loop_time) {

by

if (mean_count_A >= 12) {

to ensure that virtually all subaccumulation in the measurement loop are equal and thus can simply be added to obtain the global l_eq.

(Unfortunately the AudioAnalyzeRMS object does not return the number of buffers summed up. If both values, sum and number of buffers processed, were returned, no tight polling of the RMS object would be needed.)

I have to admit, that I did not fully understand the need for creating the 35ms sums. Can you give me a hint?

Greetings, Burkhard

PS: Got it: It´s for the min/max calculation. :-)

[hbitter]

Hi Burkhard,

yes, you are right. The time interval should be equal for the overall LAeq calculation. And thank you for the simple solution you provided. I will include it in the next version of the firmware.

You are right with the reason to have 35ms sums. It's for the min/max calculation. At the time we started, we were not sure what time to choose for the min/max values (fast 125ms, slow 1s, impulse 35ms) but yes, even for 125ms or 1s the loop would better depend on a fixed number. It's always good if someone looks a bit behind and asks. Thanks a lot, Helmut

[buv]

My pleasure!