RFC: AUDIO: Add missing (?) mutex locking to MidiDriver_MT32GM::isReady() #3038
While looking into why Lure of the Temptress takes so long to start with MT-32 audio (turns out that it's because it is setting up a lot of custom sounds?), I noticed what to me looks like a missing mutex lock in MidiDriver_MT32GM::isReady().
Lure of the Temptress calls isRead() to see if the driver has finished processing all the SysEx data. This checks if the queue is empty, but it does so without waiting for the mutex to unlock. Doesn't that mean the queue can be accessed simultaneously from two different threads?
Of course, such problems are notoriously hard to debug. I added some debug() calls, and it looked like it happened a couple of times... assuming I can count on such debug messages to be printed in the correct order.
I tried asking around, but there was no one there who could answer me. So now I'm creating this pull request to see if there's any feedback.
I posted a reply a little while ago in Discord, but that might have gotten overlooked in the traffic...
The use case for the SysEx queue is:
isReady uses Queue::isEmpty, which is a read-only operation, so it does not affect the queue in any way. The only possible issue I can see is if Queue::isEmpty returns true when the queue is not actually empty due to some concurrent modification, but I don't think it does that.