Let me just clarify: As of 1.1.7 audio rendering does not lock any mutex.
Previously, you had the option to set "synth.parallel-render" to false, causing
any thread attempting to enter fluid_synth_write_*() to acquire the lock.
However, this caused bug #192, because the current synthesization
implementation is generally not capable of this "functionality" and therefore I
hard coded "synth.parallel-render" to true. Which is the default and better
anyway, as it does not block.
@JJC: regarding your partitioning of the synth API: you're broadly correct. The
problem is, how to treat program change and program select events? On the one
hand they change midi related stuff, on the other they get down to the
soundfont loader. Given that, I think for now it is correct to only have one
mutex locking the synth.
@Marcus: I basically like the idea of doing the **smart** sample loading under
the API lock. The worst-case scenario that I currently see is that it would
block/delay incoming midi events because they're dispatched immediately to
fluid_synth_handle_midi_event(). For the midi_player this would only matter in
system clock mode. And for jack for instance this would mean we're endanger to
be kicked from the callback cycle (which is strictly speaking bug #79
though)... well low latency audio and smart sample loading are hard to befriend
I guess. Nevertheless I think we should give it a try, esp. due to the simple
fluid-dev mailing list