ESP32 with INM441 I2S microphone.

[xenpac]

Sorry, yes its a pulldown and just measured 54K, so ok.

My esp is a esp32-c3.

[MicroController]

My esp is a esp32-c3.

https://docs.espressif.com/projects/esp ... td-rx-mode
The C3 should even do better than the OG ESP32 in that the order of the samples stays intact while still omitting the un-selected channel.

[ow_birds]

@MicroController said:

So slot_bit_width must always be I2S_SLOT_BIT_WIDTH_32BIT, but data_bit_width can still be set to I2S_DATA_BIT_WIDTH_16BIT if the application only needs 16 bits.

I tried experimenting with this, because a 16 bit sample is exactly what I wanted and it removes the need for code to reduce it to a 16 bit value. But I found that by using I2S_DATA_BIT_WIDTH_16BIT the samples I got sounded like it had been s-l-o-w-e-d down (but not actually slow!), seeming to be missing the high frequencies. I don't understand why this should be. 16 bits is clearly enough to hold a decent sample, as my existing code shows.

[MicroController]

using I2S_DATA_BIT_WIDTH_16BIT the samples I got sounded like it had been s-l-o-w-e-d down (but not actually slow!), seeming to be missing the high frequencies.

Makes no real sense to me either. However, I think your original code used the least significant bits (0...15 or so) of the signal, while I2S_DATA_BIT_WIDTH_16BIT will give you only the most significant bits (8...23). Maybe there's important signal/frequencies in that low amplitude area (lowest 8 bits)? (- If you're on an ESP32, also remember to swap the odd/even samples.)

[ow_birds]

I2S_DATA_BIT_WIDTH_16BIT will give you only the most significant bits (8...23)

Ah yes. I can see this now from looking at the timing diagram.

If you're on an ESP32, also remember to swap the odd/even samples.

I'm not doing this. What am I missing?

[MicroController]

If you're on an ESP32, also remember to swap the odd/even samples.

I'm not doing this. What am I missing?

See https://docs.espressif.com/projects/esp ... td-rx-mode

In mono mode, the samples you get are in the order 1,0,3,2,5,4,..., so depending on what you want to use them for you may have to swap samples 0<->1, 2<->3, 4<->5,... Shouldn't affect the frequencies much though.

[xenpac]

In mono mode, the samples you get are in the order 1,0,3,2,5,4,..., so depending on what you want to use them for you may have to swap samples 0<->1, 2<->3, 4<->5,... Shouldn't affect the frequencies much though.

that is for the Big/Little endians word order correction on the int32 ?
this is getting more and more complicated.


Ahh we back in "mono mode". i need mono.

Me working with C3, i want my esp-driver to return me just the mono-data from the channel i selected, so no seperation extra processing is needed.
is there any example code for that?

[MicroController]

So you set slot_mode to mono, and you're still getting 'stereo' data?

[ow_birds]

Me working with C3, i want my esp-driver to return me just the mono-data from the channel i selected, so no seperation extra processing is needed.
is there any example code for that?

Are you saying that the ESP32-C3 behaves differently from the ESP32? I use the basic ESP32-WROOM-32 in MONO mode and process every sample.

After the info provided by @MicroController, I went back and tried just about every combination of slot_bit_width, data_bit_width, ws_width (16, 24 and 32 bit), bit_shift and msb_right, just to see what effect these really had in practice. Results ranged between garbage, distorted in various ways, and OK. But I didn't find a combination that worked better than what I was already using:
slot_bit_width = I2S_SLOT_BIT_WIDTH_32BIT
data_bit_width = I2S_DATA_BIT_WIDTH_32BIT
ws_width = I2S_SLOT_BIT_WIDTH_32BIT
bit_shift = true
msb_right = true
which equates to the macro use:
slot_cfg = I2S_STD_PHILIPS_SLOT_DEFAULT_CONFIG(I2S_DATA_BIT_WIDTH_32BIT, I2S_SLOT_MODE_MONO)

In theory, as I want a 16 bit value as the end result, I should have been able to start with a 16 bit data sample but I couldn't - it was always distorted in some way.

And just to revisit our disagreement on bit shifting, try looking at it this way. The 24 bit sample is right aligned, shifting it left by 8 gives the same value right aligned in a 32 value - it hasn't changed. It has to be an arithmetic shift to preserve the sign, but it's not really an arithmetic operation. But, however you look at it, our disagreement is only about the resulting magnitude, the absolute value hasn't changed. And you can apply amplification or attenuation as required to get a usable signal level.

FYI When I built the recorder originally, even though the recording sounded good, I was disappointed by the noisy spectrogram it produced (bird recordings tend to use spectrograms for visualisation of the patterns of individual species). I posted a question here:
https://electronics.stackexchange.com/q ... hone-noise
The conclusion was that the mic is inherently noisy

[MicroController]

The conclusion was that the mic is inherently noisy

Dirt-cheap, non-directional, and intended for "telecommunication applications", i.e. medium-quality speech at short ranges. You get what you pay for, I guess.

And just to revisit our disagreement on bit shifting, try looking at it this way.

No, nonono. Don't get me started