Feeding mic data: tud_audio_tx_done_post_load_cb better than _pre_ ?

[alberto-grl]

I'm trying to develop a working composite audio + CDC. On a STM32H723 it seemed I had good results.
Then I did the same on an F411, 98 MHz. It barely works and only when compiled with maximum optimization, -O3, and then a delay of 100 us in the main loop is enough to crash audio.
Then I disabled the loopback copy of speaker to mic of the example and fed data to tud_audio_tx_done_pre_cb, as suggested in the code comments. Even this needs a fast main loop. I'm calculating my data inside the pre_load_cb, it should be better to pass a pointer to a precalculated buffer I guess.
Anyway if I fill mic_buf in tud_audio_tx_done_post_cb instead of pre then it can bear a reasonable delay in the main loop, like 500 us.
The CDC part shouldn't be relevant. I tested without the cdc_task.

Unfortunately there is no example of something like a .wav player on mic.

Regards

Alberto

[alberto-grl]

Had a better look at the audio_4_channel_mic example. Here the data are prepared in the post_load callback, then written in pre_load.
I'm using tud_audio_write instead of tud_audio_write_support_ff as in this example, but I don't see any difference in just preparing data and immediately writing it in post_load. Am I missing something?
I can insert a 950 us delay and audio is still good, -O3. 850 with -O0.

Again, beware of the UAC headset example when MCU is not very fast.

https://github.com/alberto-grl/TinyUSB_UAC_CDC_411

Alberto

[HiFiPhile]

then written in pre_load.
I'm using tud_audio_write instead of tud_audio_write_support_ff as in this example, but I don't see any difference in just preparing data and immediately writing it in post_load. Am I missing something?

No, it's just an example of available callbacks.

a delay of 100 us in the main loop is enough to crash audio.
If you need to use delay in your main loop, you can put tud_task() in the ISR, like:

void USB_IRQHandler()
{
    tud_int_handler(0);
    tud_task();
}

In fact I always get better results putting tud_task() in ISR, but it could depends on differents DCD driver.

[alberto-grl]

Thanks, it is clear now. I'm testing with a delay as a quick way to guess how big is the CPU load.
Again, a 20 lines readme.txt with some basic explaination for people not particulary interested in the inner workings of USB would be welcome.

Regards
Alberto

[HiFiPhile]

@alberto-grl it's welcomed if you willing to contribute. We are a group of hobbyists who spend spared time on it while we don't have much. The project is evolving and every user's skill level is different, it's hard to come out an overkill solution.

[alberto-grl]

Unfortunately my understanding of TinyUSB is basic at best, I'm just trying to mix and match information scattered all around.
I guess this is a common feeling, most messages are from people trying to make things work by looking at code.
I agree with you about the lack of precious time, but I guess that a competent user could write a two page explanation of the basic moving parts. I guess that some people checks this awesome project but gives up because of this lack of documentation. It's a pity, it took years of work and there isn't a quick start guide. Or maybe a wiki could store pieces of info now scattered in these discussions..
Anyway in my github page there are projects for CDC + AUC2 + audio injection for STMCube.

Regards

Alberto