ESP IDF 6.01 I2S API callback on chunk of data available

[esp32.damiano]

Good morning

A key requirement when dealing with AUDIO is the short and periodic handling of a chunk of audio data

a typical time loop has a value of 20ms and every time a chunk of audio data is read, then, task waiting for the data can be waken up and act upon it.

I can have this behaviour using a "waiter task" on i2s receive, reading using something like

Code: Select all

   int retcode = i2s_channel_read(esp_audio.rx_handleP, &i2s_chunk, sizeof(i2s_chunk), &bytes_read, 100);

it works, but there is a LOT of everhead, copying bytes around, for no reason at all

there is a callback mechanism available, but as far as I know/understand it is not possible to set it up so when a chunk of data is available the callback happens.

Code: Select all

    
    static bool i2s_rx_queue_overflow_callback(i2s_chan_handle_t handle, i2s_event_data_t *event, void *user_ctx)
	{
    wicounters.i2s_rx_queue_overflow_count++;
    return false;
	}

bool i2s_rx_queue_callback(i2s_chan_handle_t handle, i2s_event_data_t *event, void *user_ctx)
	{
    wicounters.i2s_rx_queue_cb_count++;
    return false;
	}

static const i2s_event_callbacks_t i2s_callback_cfg = {
    .on_recv = i2s_rx_queue_callback,
    .on_recv_q_ovf = i2s_rx_queue_overflow_callback,
    .on_sent = NULL,
    .on_send_q_ovf = NULL,
};

what is missing is to be able to request a callback only when a well defined number of bytes is available

am I mistaken ?

[MicroController]

The overhead for copying the data is negligible (use memcpy() for that). From a callback, you want to return as quickly as possible anyway, and the fastest way of "processing" data inside the callback is to just copy it elsewhere.

I2S operates on DMA buffers, and that's what you get in the callbacks, because the driver itself is only notified when a DMA buffer finishes.

[esp32.damiano]

Please, read again the question I posted

I know I can be notified when "data is available", the question is "I wish to be notified when a well defined number of bytes are available"

so far, your answer is "no, you get called up on unknown amount of data"

[MicroController]

Please, read again the question I posted

Done.

am I mistaken ?

Yes. The driver (and the hardware) define the amount of data you receive in the callback. And that's fine for everybody so far.
You can receive the data via callback in DMA-buffer sized chunks, or via blocking reads in chunks of your desired size.

Edit:
You should be able to set the DMA buffer size via i2s_chan_config_t::dma_frame_num.

[esp32.damiano]

You must be an AI, that does not understand the question

setting the DMA size to exactly the buffer I wish to receive will lead to dropped frames.
You do not want dropped frames, do you ?

The are plenty of developers that do NOT tell how things could be better, ok, we know that

I am saying that there is value to have a callback that happens when the requested number of frames are available in I2S.

At ISR level, no tasks (less memory wasted), less CPU wasted in context switch and semaphores

[MicroController]

I don't think that I'm an AI. - But maybe I am and only programmed to think otherwise? Will go and try some CAPTCHAs to find out.

You do not want dropped frames, do you ?

Rather not. But I also don't get any frames dropped. Why would I?

I am saying that there is value to have a callback that happens when the requested number of frames are available in I2S.

I am pretty certain that you are not an AI, because you keep ignoring things you have been told. Most importantly: "You can receive the data via callback in DMA-buffer sized chunks" - Again: That's how the hardware works, and the software/driver can't change anything about it.

Btw: A context switch usually takes between 10 and 20us. Assuming 20us and taking your 20ms "loop time" (i.e. 50*2=100 context switches per second), we end up with 2ms of CPU time per second (0.2%) spent on the switching. Is this "a LOT of overhead"? - Depends, I guess.