TinyUsb High Speed FreeRTOS audio micro frames linear buffer

[jmf13]

As explained in earlier post, I work on a USB to I2S_TDM bridge supporting 8 channels. The platform will be ESP32-P4. It is working OK for 8ch 16bits and 48k which can be contained into an Iso frame sent every 1ms. But to achieve higher sampling rate, I need more frames per ms, so I moved to bInterval 1, which corresponds to 1 micro frame every 125 micro second (us). And this is not working well any more: disturbed audio, cracking noises... Which forces me to better understand how the overal thing is working and how to best use it.

For context, I made some previous developments based on stm32 platforms where the DMA can do lot of the magic autonomously behind the scene: move data from USB to intermediate buffer, then to I2S. It seems that it is not the case on the ESP32 (even P4) and that the data have to be copied several times through the pipe. And I was working baremetal, where ESP32 enforces FreeRTOS. Still advantages to ESP32-P4 for that scope: it has embedded USB HS Phy and you can find cheap modules easy to solder to application boards.

First question:
When there is a data micro-frame every 125us, will TinyUSB collect all data in the Linear Buffer without dropping frames even i the tick is 1ms (and audio task may have higher priority) ?
I understand that the Events are queued from ISR and processed in tud_task(), but what happens to the frame data in between ?

Second question:
On ESP32 plateform, I understand that the expected usage would be to have an audio task running in parallel of tud_task(). That audio would periodically pull the data from TinyUSB and push those to i2s. Is there a way to do this without an needing intermediate buffer, to avoid below:

• tud_audio_read(intermediate_buffer, length); <= first memcp
• i2s_channel_write(intermediate_buffer, length); <= second memcp

Third question (in case of):
Any advised better "architecture" to achieve high bandwidth with TinyUSB on ESP32 ?
Ideal target would be 8ch 32bits 96k

Best regards,

JM

[HiFiPhile]

When there is a data micro-frame every 125us, will TinyUSB collect all data in the Linear Buffer without dropping frames even i the tick is 1ms (and audio task may have higher priority) ?
I understand that the Events are queued from ISR and processed in tud_task(), but what happens to the frame data in between ?

Since some time ago ISO transfers are fully managed inside ISR. For non-ISO transfer with RTOS, tud_task() will be executed as soon as any event is queued from ISR due to preemptive scheduling.

On ESP32 plateform, I understand that the expected usage would be to have an audio task running in parallel of tud_task(). That audio would periodically pull the data from TinyUSB and push those to i2s. Is there a way to do this without an needing intermediate buffer, to avoid below:

As stated in examples, audio_task() is only used to simulate I2S interrupt.

The right way is pulling data inside I2S interrupt with either:

• tud_audio_read to read buffer into I2S ping-pong buffer or an intermediate buffer for pre-processing
• tud_audio_get_ep_out_ff + tu_fifo_get_read_info + tu_fifo_advance_read_pointer to read data directly from UAC FIFO

[jmf13]

Thanks a lot HifiPhile for the explanations.

So no data loss from micro-frames to be expected because of the tick value (if enough CPU power) : Good !

If the intermediate buffer and related copies generates too high CPU load, I will experiment based on your indications, especially the tud_audio_get_ep_out_ff + tu_fifo_get_read_info + tu_fifo_advance_read_pointer to read data directly from UAC FIFO.

I imagine that it is good to have the operation with the TinyUSB fifo buffer about half filled so that it can buffer on both sides. So the startup process would be to let "accumulate" in the TinyUSB fifo buffer about this 50% amount before starting reading. And from that point start to pull "reasonable" chunks (like 10%-20% buffer size). Does this looks correct ?

[HiFiPhile]

I imagine that it is good to have the operation with the TinyUSB fifo buffer about half filled so that it can buffer on both sides. So the startup process would be to let "accumulate" in the TinyUSB fifo buffer about this 50% amount before starting reading. And from that point start to pull "reasonable" chunks (like 10%-20% buffer size). Does this looks correct ?

Yes it's good.