So, there are two things here: one is that sometimes it takes about 55 seconds (~9 sec per canard) and sometimes it takes 35 seconds (~5.5 sec per canard).
The other thing is that sometimes canard crashes when loading the samples.
For the first one, the slower loading happens when canard is running while it’s loading. I mentioned in another thread (Options menu not showing up - #12 by danngreen) how it tries to create new async threads repeatedly while it waits for the first one to load. There might be other things its doing while loading that are causing it to slow down. So that should be fixed in the Canard code. Probably we can have it load the initial file in the normal thread (no Async thread) and that will solve it.
I don’t know yet why it crashes sometimes, but I still suspect that it’s something to do with the fact the Async threads launching outside of the audio context.
What I’ll do is put a little guard in the firmware repo to stall the audio from loading until all async threads have been launched (which is what was happening on my locally built version – why it was loading in 35 seconds because I have console debug logging enabled while caused the short delay before audio started). It’s just a band-aid, though.
I think the real solution is I need to do a better job documenting usage of AsyncThreads.
I started refactoring Canard, to make it more safe between the GUI and audio threads, I’ll continue there.
Also the STSP uses AsyncThreads to stream from disk to the buffer, so I could just finish that!