Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts

[Tom M.]

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