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 implementation. Tom _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
