I have just committed the changes to the fluid_synth class, which means
that the new architecture is in place. With that I hope that the
reordering issues (tickets #65, #76, #79) are gone for good.
There are two new settings controlling the thread safety,
synth.threadsafe-api and synth.parallel-render (I don't mind better name
suggestions).
synth.threadsafe-api controls whether the synth's public API is
protected by a mutex or not. Default is on, turn it off for slightly
better performance if you know you're only accessing the synth from one
thread only, this could be the case in many embedded use cases for
example. Fluidsynth executable can use many threads (shell is one, midi
driver is one, midi player is one) so you should usually leave it on.
synth.parallel-render is the low-latency setting. If on, you're allowed
to call fluid_synth_write_s16, fluid_synth_write_float,
fluid_synth_nwrite_float or fluid_synth_process in parallel with the
rest of the calls, and it won't be blocked by time intensive calls to
the synth. Turn it off if throughput is more important than latency, e g
in rendering-to-file scenarios where underruns is not an issue.
Some cleanup and testing remains, at least:
* Update autotools build system (currently CMake is updated)
* Go through fluid_synth_t and see what is currently atomic and shadowed
and what could be changed to ordinary variables
* See if there are other public API functions (apart from synth.h) which
should be mutex protected
* Move multi-thread rendering to the voice_mixer
* Revisit voice-stealing algorithm
* I've tried fast rendering and live keyboard playing, but many more use
cases remains to be tested, help is welcome!
Enjoy!
// David
_______________________________________________
fluid-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fluid-dev