DMIC pop / click sounds between each memory block

[timonsku]

I'm trying to continuously stream data from the dmic interface, in this case over serial though only for testing.
Things seem to be largely working except for pop/click artifacts between every block.
In this case the memory slab is setup for 4 blocks with enough memory for 100ms of audio, default settings taken from the dmic sample.
The pop is usually about 0.5-1ms long and per recording looks exactly the same each time and occurs in intervals equal to the block size. Large block size means less frequent intervals.

This smells like either samples are dropped between each block or I'm getting garbage data inserted somehow, though it does feel more like audio is missing/overwritten when a pop occurs.
Giving a really large block size like 1000ms of audio make the pop occasionally not occur.

My understanding is that the dmic driver continuously reads data as soon as the start flag is given and will choose a free memory block from the slab to write to. As long as I process a returned block quickly enough and free it then the dmic should not run out of memory or drop samples (if that is even a possible behaviour)?
I can't see an off by one error or similar in the way I grab the data either. It's a bit puzzling.
The interface is not throwing me any errors with debug log enabled.

Attached a sample recording and the project code. The python script can be used to translate the ASCII HEX string to a binary.

Using NCS 2.5.0

3527.dmic.zip

5684.silence_with_clicks.zip

[ovrebekk]

Hi Timon

I ended up with this case also. Unfortunately we are severely understaffed during the Christmas period, and I will have to investigate further next week. I apologize for the inconvenience. 

Best regards
Torbjørn

[timonsku]

Hi ovrebekk  totally understand!

[ovrebekk]

Hi Timon

For some reason the dmic.zip attachment is not able to load (the other attachment works). Would you be able to attach this file one more time? 

Best regards
Torbjørn

[timonsku]

Oh weird, I edited the post with a new upload. Can you try again?

[ovrebekk]

Hi Timon

Thanks, now I could download all the files

My main concern looking at your code is the fact that you are printing all the data to the console using printk(), this might introduce quite a lot of delay in the main loop. Could you try to comment this out and see if the pops go away? 

Best regards
Torbjørn

[timonsku]

Hi Torbjørn,

the UART is set close to 1M Baud, that should be more than enough in theoery.

The pop occurs even at lower baud rates without a noticable change and given the dmic reads via DMA I don't think that could cause a hickup? If its due to being too slow to free the memory blocks then I should get 4 click free blocks before seeing clicks but this is not the case.

I only have the UART to check the validity of the samples. Printk via logging is disabled so the logging infrastructure should not interfere or be an overhead.

[ovrebekk]

Hi Timon

timonsku said:

the UART is set close to 1M Baud, that should be more than enough in theoery.

Hm, I would say it is just about enough. 

16000 samples/sec * 5 ascii characters pr sample * 10 bits pr character (including stop and start bit) = 800kBaud

So it is enough, yes, but not by a large factor. The question is how much overhead there is in the driver, and how much CPU time is required to process all those samples and convert them to a string, before passing them to the UART driver. 

I would suggest running a quick test just changing num_samples in the loop to a small number like 10 and see if it makes a difference. 

A colleague of mine recently did some work integrating a PDM mic on the nRF52832, and the code looks very similar:
https://github.com/Noy0908/smart_remote/blob/desktop_remote/src/smart_remote/drv_mic.c#L191-L218

By the way, how do you transfer the audio data to the PC for analysis? 
If you still can't make it work I will try to replicate your test here, but I need to figure out the easiest way of transferring the audio data somewhere else for playback. Maybe storing to SD card on the audio DK is the best bet...

Best regards
Torbjørn

[timonsku]

I had tested fewer samples before, even just doing a single block results in having at least one click. The only times I saw a click sometimes not appear was with increasing block size significantly but it was inconsistent with some blocks having it and some not.

I dump the samples by connecting via USB to a PC and saving the serial output to a file/logging it and use the python script in the project zip file to turn it from ASCII into a binary file. That binary file I then open in Adobe Audition by doing a raw PCM import. Audacity would probably also work.
For the serial logging I use "tio" on an Ubuntu machine but any serial terminal should do it including the VSCode one that Nordic ships.

Thanks for the link, I will see if there is anything significantly different that I can try.