ESP32 Forum

Dear L-KAYA,

I have the result of your provided code. I did not change anything in your configuration. However, still I am getting missing sample in data.
Following are the log message from my device. Let me know if you need any kind of information.
Looking forward to hearing from you soon.

Hi shailesh.korat,

Glad to see you!
For the first question, here is the explanation for overtime_tick:

Meaning
1. Generally speaking, 'overtime_tick' is the ticks that 'i2s_read' should cost, that means, if the i2s_read task wait for more than 'overtime_tick', there must be data dropped.
2. 'overtime_tick' can also be treat as 'i2s_read' blocking time when there is no data lost.

Calculation
1. Since we have knew the channel number and the bits in one channel, then we can calculate the total bytes in one frame is:
frame_bytes = chan_num * bits_per_sample / 8
2. Then we can know the how many bytes there will be in one second (i.e. byte rate)
byte_rate = frame_bytes * sample_rate
3. Finally we can get the time for receiving EXAMPLE_RECV_BUF_SIZE will cost:
recv_time = EXAMPLE_RECV_BUF_SIZE / byte_rate
4. Transfer to miliseconds
overtime_tick = recv_time * 1000

-----------------------------------------------------

For the test result,

I notice that i2s_read block time is short. In the normal case, the block time should always be around 'recv_time' that mentioned above, that means the received data are taken from message queue immediately, the queue is always empty, i2s_read has to keep waiting for the data from message queue until the receive buffer is filled up. So no data will be dropped, and the 'recv_time' is equal to 'i2s_read' block time. But when the i2s_read block time is short, it means the message queue is always full, so that i2s_read can get data immediately from message queue without any block. Since the data in message queue can't be taken timely, the old data will be dropped to input new data, then you can see the data lost.

I see your wave looks much better after allocating a bigger receive buffer, my suggestion is keeping increase the receive buffer, a big buffer should always help.

Dear L-KAYA,

Thank you for giving nice explanation.

Few question regarding i2s APIs function call.

1) what is the meaning of dma_buf_count = 8 which are passing during driver_install call?
Does it mean that DMA will create message queue ( size 8 buffer) of dma_buf_len to read data from i2s ?

2)You said that i2s_read block time is short, it means the message queue is always full, However I could not see any buffer overflow with following method. It should print right? 3) You said allocating a bigger receive buffer should always help. Is this kind of limitation from ESP IDF that I need to keep bigger buffer?

4) i2s_driver_installcall already started DMA , reading data from I2S and storing into DMA message queue,if I will use i2s_read call sometime after it means the message queue is always full, so that i2s_read can get data immediately from message queue without any block. Since the data in message queue can't be taken timely, the old data will be dropped to input new data? Am I understand correctly?

5) Lets say I want to read 192 samples at time (192 * 8= 1536 bytes, where frame_bytes = 8) from i2s_read call, how could it possible?

Happy to provide more information if need.

Thanks.

Dear shailesh.korat,

You asked really good questions! Actually some answers already on the way, you will see them in programming guide soon.

A1: dma_buf_count: The total number of descriptors used by I2S DMA to receive/transmit data. A descriptor includes some information such as buffer address, the address of the next descriptor, and the buffer length. Since one descriptor points to one buffer, therefore, dma_buf_count can be interpreted as the total number of DMA buffers used to store data from DMA intterrupt. Notice that these buffers internal to i2s_read and descriptors are created automatically inside of the I2S driver, users only need to set their number while the length is derived from the parameter described below. In addition, the DMA message queue length is equal to dma_buf_count - 1, in case of covering the data that haven't read.

dma_buf_len: The number of frames for one-time sampling. The frame here means the total data from all the channels in one WS cycle. For example, two channels in stereo mode (i.e., channel_format is set to I2S_CHANNEL_FMT_RIGHT_LEFT) are active, and each channel transfers 32 bits (i.e., bits_per_sample is set to I2S_BITS_PER_CHAN_32BIT). Then the total number of bytes of a frame is channel_format * bits_per_sample = 2 * 32 / 8 = 8 bytes. For example, we assume that the current dma_frame_num is 100, then the length of the DMA buffer is 8 * 100 = 800 bytes. In addition, the length of an internal DMA buffer shouldn't be greater than 4092.

A2: Yes, your method is right, but this is a bug, it will be fixed together with the update of programming guide, then you can catch the overflow event.

A3: From my understanding, the slower you process the data, the bigger buffer you need. So I think it is mainly depends on the complexity rather than the limitation of IDF.

A4: Partly right. Although the message queue will overflow if i2s_read not called, it can still be taken to underflow as long as the speed of i2s_read is faster than receive. Otherwise, the message queue will always be overflow if the speed of i2s_read can't catch the speed of data receiving from ISR.

A5: If you want to read 192 samples for one-time i2s_read, firstly you should allocate a 1536 bytes buffer for reading. Secondly, dma_buf_len should be smaller than 192, smaller than 192/2 = 96 will be better, here is the reason:

If the dma buffer size is greater than the user given buffer size, it means we need several loops of i2s_read to take all the data in one dma buffer, the max_wait_time will be squeezed to avoid message queue overflow. Therefore it is quite risky to give a small buffer for data receiving when calling i2s_read.

----------------------------------------------------------------------
There are couple of tips:

1. Increasing dma_buf_len can help to reduce the I2S DMA interrupt frequency;

2. Increasing dma_buf_count can help to increase the max wait time that spent by other operations in i2s_read loop;
3. Increasing the receive buffer size that give into i2s_read can help to increase the block time of i2s_read function . When you process I2S data (like store them to a SD card) in another thread, the time that spent in processing thread for one loop should not beyond this block time, otherwise there may have data lost. So if it's really slow on dealing with I2S data, please allocate a big receive buffer for storing the read data;

4. Allocating at least two receiving buffers can improve the efficiency. One can continue to receive data while another buffer is under processing. But we have to guarantee the buffer that going to read data is not under processing in other thread, we can use semaphore or other lock to avoid covering the data in the buffer while it is still under processing;
5. Increasing the priority of the thread that contains i2s_read can help the data in message queue to be taken more timely.