Essentially we agree, as I said, it's just an issue of magnitude. In my opinion, if you treat the 24 bit value (which it is, the spec says so) as a 32 bit value, you're seeing it 256x larger than it really is. But that's fine if you're always going to adjust it to whatever is usable. Peace.

No, nonono. Don't get me started

No, please do! Explain how I should be processing this 24 bit sample.

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 ...

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 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 ...

Apparently, the ESP32's I2S can be configured to ignore either channel (I2S_RX_FIFO_MOD "mode 3", "32-bit single channel data"), and the docs seem to confirm that only the selected channel's data is returned.

Btw, it may be a good idea to enable the pull-up or pull-down on the data pin as ...

2) With only one mic, the master will still clock in both left and right samples alternatingly, but one of the channels contains no data, or only digital noise from the floating data line.



So does this mean every other sample I get is garbage, to be ignored? Currently I process every sample ...

I admit to not fully understanding how the INMP441 interface works :-( I looked at many (and contradictory!) examples online, especially https://github.com/kaloprojects/KALO-ESP32-Voice-Assistant lib_audio_recording.ino to get my code working, which it does appears to - it's deployed in two bird ...

We'll just have to agree to disagree about this.

In the actual code, I do check that the value will fit into a int16_t:

// check for int16_t overflow
signal_overflow = signal_overflow || val32 < SHRT_MIN || val32 > SHRT_MAX;
signalMax = max(val32, signalMax);
signalMin = min(val32, signalMin ...

Because a left-aligned 24-bit value in a 32-bit integer is numerically 'too big' by a factor of 2^8.

But it's not a 32 bit integer, yet. The original value is 24 bit, and the shift is just moving it into the correct position and making it a 32 bit value. It's not an arithmetic shift because the ...