We’re seeing audio glitches when calling MidiOutput::sendBlockOfMessages from the audio thread.
It looks like ScheduledEventThread holds its mutex while waiting and while sending MIDI (UMP conversion + native send). At the same time the audio thread calls addEvent, so it can block on that lock and cause glitches, especially when several nodes share the same MidiOutput.
In JUCE 8.0.10, MidiOutput only locked to pop-out a message from the queue, then did the wait/send unlocked. That didn’t cause this problem.
As a temporary workaround we’ve reverted juce_ScheduledEventThread.h to the 8.0.10 version.
Happy to help with more details or testing if useful.
Is MidiOutput supposed to be real-time safe? I’m not arguing that these improvements made sense, but if that is now (or was ever) part of the contract, this wasn’t documented anywhere I can find.
I tried to make the functions that send messages immediately realtime-safe, although the OS APIs themselves aren’t documented to be realtime safe in many cases. There’s also a caveat that these functions are not necessarily realtime safe if you have multiple threads all simultaneously sending messages to the same output, since accesses to the output must then be synchronised.
The functions that enqueue messages to be sent in the future aren’t realtime safe, currently. Therefore, the use-case mentioned at the top of this thread is not recommended, but it also highlighted a valid concern. Holding the lock unnecessarily would stall any thread adding messages to the queue, and we don’t want to do that even for non-realtime threads.
