> Let me just clarify: As of 1.1.7 audio rendering does not lock any mutex.
Thanks for recalling this and the use of "synth.parallel-render" to true to
avoid audio rendering API locking the mutex.
>The worst-case scenario that I currently see is that it would block/delay
>incoming mid
I cannot really help you to integrate fluidsynth to android. It has been
discussed several times on the mailing list (just search the fluid-dev archive)
but there was no real conlusion how to do it, much less a definite guide. I am
convinced that fluidsynth can be run on android, by cross compli
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
i
Hi JJC,
I don't think the audio rendering uses the same mutex, otherwise you would
get audio dropouts if you were loading a large soundfont while sound is
being played. The API gets locked, so you can't add any more notes or
change the sound, but already started notes carry on playing. Or am I
mis
Hi,
>Does anybody see a drawback in doing the lazy sample loading in-thread under
>the API lock?
Yes actually the potential drawback exists seriously and i understand your
fears but fortunately the actual inner fluidsynth structure make things easy to
solve this (i guess :), unless i have mi
