Page 1 of 1

Q: I2S receiving buffer size

Posted: Tue Nov 28, 2023 8:09 pm
by apuder
Hi,

I understand the need for more than 1 DMA buffer to ensure continuous reading of I2S data. I assume for two DMA buffers, the CPU processes one buffer while DMA fills the second and then repeats the process by flipping the buffers. The documentation states that recv_buffer_size > dma_buf_count * dma_buffer_size. That puzzles me a bit. A receive buffer size that spans all DMA buffers would mean that i2s_read() would only return when all DMA buffers are filled. Shouldn't the receive buffer size be just the size of one DMA buffer? FYI: I'm still on ESP-IDF version 4.

TIA,
AP

Re: Q: I2S receiving buffer size

Posted: Sat Mar 30, 2024 10:55 pm
by apuder
Hi all: I am still puzzled by my question from last November. Any knowledgeable soul out there know the answer?

AP

Re: Q: I2S receiving buffer size

Posted: Sun Mar 31, 2024 4:28 am
by ESP_Sprite
I think the logic is that in a situation of extreme CPU pressure, it is 'cheaper' to read out all DMA buffers at the same time rather than to have separate calls to i2s_channel_read(). In the event of a very busy CPU, you'd want to empty all DMA buffers anyway, so you have more space to 'fill up' when the task doing i2s_channel_read() is blocked.

Re: Q: I2S receiving buffer size

Posted: Tue Jul 16, 2024 11:29 pm
by noweare
ESP_Sprite wrote:
Sun Mar 31, 2024 4:28 am
I think the logic is that in a situation of extreme CPU pressure, it is 'cheaper' to read out all DMA buffers at the same time rather than to have separate calls to i2s_channel_read(). In the event of a very busy CPU, you'd want to empty all DMA buffers anyway, so you have more space to 'fill up' when the task doing i2s_channel_read() is blocked.
I see what your saying, but if you let all buffers fill up before reading the source has no place to put the data. If you have, for example 2 or more buffers, you get the advantage of simultaneously reading the filled buffer and your source filling up the next empty buffer. This will reduce the latency.

Re: Q: I2S receiving buffer size

Posted: Wed Jul 17, 2024 1:40 am
by noweare
apuder wrote:
Tue Nov 28, 2023 8:09 pm
The documentation states that recv_buffer_size > dma_buf_count * dma_buffer_size. That puzzles me a bit. A receive buffer size that spans all DMA buffers would mean that i2s_read() would only return when all DMA buffers are filled. Shouldn't the receive buffer size be just the size of one DMA buffer? FYI: I'm still on ESP-IDF version 4.
You don't have to wait until all the dma buffers are all full. The I2S_EVENT_RX_DONE event gets fired when ANY of your dma buffers get full then you can read that dma buffer. You just have to keep advancing the pointer in your buffer so what you read previously is not over written.

Same with I2S_EVENT_TX_DONE. Each time that event occurs you can start writing to the tx dma buffer.

This makes sense as it decreases latency and both operations are happening at the same time.

Re: Q: I2S receiving buffer size

Posted: Wed Jul 17, 2024 6:58 am
by ESP_Sprite
Ideally, you'd empty those buffers immediately indeed, for lowest latency. However, we're talking about a CPU that also needs to do other things: handle peripherals, talk over WiFi/BT, perhaps writing to flash... in case you cannot empty those buffers as soon as you can, it's good to have some 'wiggle room' in the form of extra buffers the hardware can fill up so you don't get an overrun anywhere.

Re: Q: I2S receiving buffer size

Posted: Thu Jul 25, 2024 7:58 pm
by apuder
Sorry, but I'm still a little unclear. The documentation for i2s_read() says for the output parameter bytes_read, "Number of bytes read, if timeout, bytes read will be less than the size passed in". It sounds like if you pass portMAX_DELAY for no timeout, the number of bytes read will be the number of bytes requested. In that case it would seem to me that the CPU would have to immediately process the data for DMA to be able to fill the next buffer. That seems to contradict the argument that the CPU may be busy doing different things.