PDM / DMIC not giving any sensible output

[timonsku]

I'm trying to capture audio data from a PDM microphone.
Using the dmic sample I output the captured buffer via serial. Though the captured PCM data is 8x the same data. So each time the dmic sample captures one "block" is receives the same data though this is not what I see in my logic analyser.
What is even more puzzling is that I keep getting successful data reads when I disconnect the microphone. That happens with the unmodified dmic sample.

The issue sounds very similar to this old ticket: RE: Trouble extracting data using DMIC 

Used hardware:
nrF5340DK
Microphone: https://www.adafruit.com/product/4346 ( https://cdn-learn.adafruit.com/assets/assets/000/049/977/original/MP34DT01-M.pdf)

Software:
NCS2.5.0 via VSCode Extension
Windows 10

The received output. 1. Zoomed in 2. Full capture

[Maria Gilje]

Hello,

I have picked this up and will get back to you soon. But let's start with some clarification questions:

What is even more puzzling is that I keep getting successful data reads when I disconnect the microphone.

How to you disconnect the microphone?

How do you define "successful data reads"?

Best regards,

Maria

[timonsku]

Hi Maria,

I remove the data and clock line from the development kit, then I press the reset button, the firmware reboots and still prints out sample data. This also happens with the unmodified dmic sample where it reports successful reads from the interface. E.g. this line is not triggered because dmic_read returned with 0 which it should not have with no physical device present to return audio data.
https://github.com/nrfconnect/sdk-zephyr/blob/main/samples/drivers/audio/dmic/src/main.c#L58C12-L58C12

It tried both nrf5340dk_nrf5340_cpuapp and nrf5340dk_nrf5340_cpuapp_ns build targets, same outcome.

[poplitard]

That's because dmic uses DMA, it allocates some memory to write microphone data

dmic_read returns a buffer address and the size of that buffer

It's all good if the microphone returned any data and the buffer was updated, otherwise the buffer is going to have some garbage values 

[timonsku]

But that should raise an error for a read and not just continue to provide data while not receiving any data? That would make sense to me if the device disconnected during a read but that it configures and starts reading successfully without any hardware connected is odd.

[timonsku]

I did make some progress though. Reconfiguring the pdm interface with every block read was partially an issue it seems.
Still getting some periodic popping artifacts that I can't really explain so far but behind the artifacts I can at at least hear the recorded audio now.

[timonsku]

poplitard not sure if the system is weird or if you deleted your reply. I'm currently doing a start, read and stop cycle in a loop. Mostly the dmic sample but moved the configuration out of the transfer function.
I'm not quite sure what the proper way is to do a continues read stream. I've been going through the Thingy:53 firmware but its quite abstracted and verbose so hard to track down how exactly that is handled for audio streaming.

[poplitard]

I deleted my reply 

I think you'd configure then trigger start and continuously do a dmic_read but when I tried that I got clicking noises like you so I'm still trying to figure that out

[timonsku]

ah I just realize you are the same person with that other similar ticket
I'm actually using a modified version of the code you had posted, thanks for that, it helped me get a bit further with this.
My pops are a bit more aggressive than the pcm sample you had posted so I figured that might be related to reading too much data maybe and getting a few random bytes in there.
Thats unfortunate that you still get the pops if you don't stop the stream at all. Altho I guess the memory slab could still contain some "off bytes" if the dmic driver isn't completely filling it for some reason or notifies too early.
I did see a notice about a workaround to get rid of click sounds in the Thingy:53 firmware. Let me see if I can find that again.

[timonsku]

Ah found it but it unfortunately suggest that the click is something that happens once when the interface is started, so if you don't stop it again I would expect the pop to not re-appear :/
github.com/.../ei_microphone.cpp