Baby cry passband filter

[Rvh91]

To me a great application for the microphone would be to detect baby cries. I Noticed that thresholding based purely on A or Z weighting would prove difficult, due to different background level noises. According to literature, the cry of a baby is predominantly located in the 400 to 650Hz range. It would be great if we could easily construct additional weighting filters based on a certain frequency.

Would it be possible to construct a filter with a GUI to automatically obtain the sos filter coefficients?

[stas-sl]

TBH I'm not really a DSP expert, I learned a bit while working on this project, but it is complicated topic.

Nevertheless, it is definitely possible to construct band pass filter that you described. I'm not sure what's your DSP/math/programming background, but you can check out my notebook (if you've not seen it yet) to learn how to work with filters in python and how to convert them to SOS form. Actually it could be as simple as calling scipy.signal.butter with required parameters. But you have to be careful specifying correct parameter values and using obtained coefficients with correct sign. To double check, you might use sosfreqz to obtain frequency response of your filter and plot it. Or you can actually record the sound, load it in notebook, plot its spectrogram/psd using matplotlib to see what frequencies are there, then apply filter to it and again plot resulting spectrogram or just listen to it to verify that the filter is working.

Probably there are other tools like MATLAB or online GUI where you can do the same, but I'm just sharing what I'm more familiar with and what was using.

[Rvh91]

clear! thanks! :) I noticed that sometimes I get the warning:

[09:45:19][D][sensor:094]: 'LApeak_1min *** ***': Sending state 66.70847 dBA with 2 decimals of accuracy
[09:45:19][W][component:204]: Component sound_level_meter took a long time for an operation (0.17 s).
[09:45:19][W][component:205]: Components should block for at most 20-30ms.

could it be that the _1min sensors are more intensive on the runtime? I had an issue where the device wouldnt boot, when I added my 'cry' sensors. I noticed your comments on performance, but I'm not entirely sure how to read what the maximum allowed amount of sos filters and level sensors are. For example, is it cheaper to remove all the LZ values, or am I better of reducing the update interval for example?

Do you see value in the LZ values by the way? or is LA / LC mostly of importance?

[Rvh91]

I also notice that the processing time is much higher.
[10:34:16][D][sound_level_meter:120]: Processing time per 1s of audio data (48000 samples): 599 ms

I'm not sure how to obtain the CPU frequency from ESPhome. I'm using a esp32-S2, which is reported to be running at 240MHz (single core if that matters). But this is quite different from the 210ms you reported.

[stas-sl]

Aggregation period (update_interval) doesn't affect performance, it could be seconds, minutes or even hours. What matters is number of filters (number of SOS sections to be precise, each line of coefficients is a section) and number of sensors. So processing time = A * num_sos_sections + B * num_sensors. I don't remember exact numbers but I believe A > B.

Having 599ms processing time doesn't mean that it blocks main loop for that long, data is processed in small chunks of buffer_size samples in a separate task, but as there is only a single core it could affect main loop performance I guess.

You can set CPU frequency in config (platformio options, google it), but I guess it should be 240MHz by default, but you can try setting other values explicitly.

You can also try with same number of sensors as in my performance section table to compare with your results. I was running on regular ESP32 (not S2) which has 2 240MHz cores. 599ms seems indeed a bit too much if you added only a few additional filters and sensors. Though even in that case it has ~40% of free CPU time for other tasks. System critical tasks like WiFi should be running with higher priority and you can adjust sound_level_meter task_priority in config. It is set to 2 by default - the lower the number the lower the priority. 0 - means idle. So you can try to set it to 0.

I mostly monitor LA_* values, LZ_* I used for debugging initially.

[Rvh91]

Mhh alright, thats a bit weird. I changed the update_interval from 60s to 10s, and it seemed to make quite a difference. Also, removing the sensors with a larger sample period seems to make more of an impact. I also only got the warning after these sensor reported their values, not on the 1s sensors.

[stas-sl]

What do you mean by "quite difference"? Do you see this warning consistently after each update of 1 min sensors? Do you see difference in processing time when using different update_intervals? Can you show what those numbers are?

Data is aggregated continuously per each buffer_size blocks and only total sum and count are stored. So all heavy processing is performed identically for 1 sec/1 min/1 hour. On each update interval it just has to take those 2 numbers divide, take log - and basically that is all.