I’ve been working on a sampler built on top of the juce::Synthesizer class. In many functions the Synthesizer locks a mutex, including at the start of the processing callback. I was wondering why this is used and how is it real time safe? In the docs it says “This is used to control access to the rendering callback and the note trigger methods.” but who else is calling them? I haven’t come across any audio dropouts or glitches so far but isn’t there a possibility of priority inversion if the audio thread tries to render while another thread has the mutex locked? For example, when adding sounds. I actually need to share a container between the audio and the UI thread and I was wondering if I can use the same mutex to control access to that as well. I might be missing something so I’d really appreciate it if someone could enlighten me about this.
I wouldn’t use the synth mutex on the UI, I assumed it was because it was all in one thread. It was a safety precaution that would effect realtime performance too much.
I have 3 oscillators and 3 wavetables and shared them by reference between UI and Audio. If you have all audio output suspended, and painting suspended {or not being called yet} while creating the memory and writing to it, I think it is safe to read data between threads, as long as it is not currently being written to by another thread, unless it’s atomic.
I use a mutex and scoped lock while loading files to a buffer, so that the same function doesn’t get called while the other one is completing by a user hammering a button several times in a row. Within that mutex function I use an atomic bool that suspends the audio. If you’re using Juce buffers I think you can just call suspend.
If you need realtime audio output, I would just fifo buffers. Then you are never reading and writing from two different places at the same time. ~ torn binary ~
