Hi all,
While trying to use Fluidsynth 1.1.3 with JACK in realtime mode, I've
noticed that Fluidsynth tends to get removed from the graph on first
processed block, due to excessive time spent in the process function.
This makes it practically impossible to use Fluidsynth in that context.
I've looked at the code, and isolated the problem to the
new_fluid_chorus function called from event handling code, as the first
event to be handled. This function not only calls malloc (non RT-safe),
but also calculates a 1280-item sinc table and zeroes a delay line -
which might take plenty of time that might not be available in realtime
callback.
I think there are some improvements that might make Fluidsynth
compatible with realtime mode:
1. Pre-allocating the chorus object. Changing the sample rate doesn't
require full removal and re-creation of the chorus object, it's probably
enough to just update the sinc values and some other things.
2. Not changing lookup table size depending on sample rate - a fixed
size table plus interpolation might be good enough for chorus.
3. Not using fluid_rvoice_mixer_set_samplerate event when not required,
and certainly not at startup. It's probably sufficient to query sample
rate on startup and set it in non-realtime context. This won't help when
sample rate is changed "on the fly", but it's a very uncommon scenario,
and not currently possible with JACK.
Or maybe the first batch of events could be dispatched before sound
processing is started - in case of JACK, that would be before a call to
jack_activate, from a non-realtime thread. This way, all the "startup"
events would be processed with no realtime requirement, which would
sidestep the problem with new_fluid_chorus.
jack_flush_queue.patch