Hmm…
There’s another thing, the Async run_once gets called repeatedly (50+ times) for short samples. I’m not sure how that plays out with the lock(), it’s clearly not loading from disk 50 times, but it’s probably not good to have this. I’ll put in a check for the lock before calling the run_once.
There are some concurrency issues in the Canard, too. I’m trying to make sense of it – the lock() can’t appear in the audio thread (that will freeze the audio thread if the GUI thread locks it, but only if the module is running on the same core as the GUI, which is 50% of the time). Maybe the purpose of the big copy for the rendering was to avoid some of these issues, but even with the copy present, it could make the audio thread freeze (consider if a trigger into Clear was fired while the gui was copying the sample data – we would get a deadlock). One way or another the threads need to share the data and not crash if one decides to clear the buffer while another is reading it.