Re: [fluid-dev] JACK connection problems with fluidsynth

[Shamus]

On 05/24/11 01:52, David Henningsson wrote:
> On 2011-05-23 16:51, Shamus wrote:
>> The latency on JACK is 11.6 msec, according to QJackCtl, and this is
>> already skating on the high side of things. I have it set to 256 frames,
>> 2 periods/buffer at a sample rate of 44.1KHz.
> 
> So resetting would take more than ~ 5 ms then...that's pretty much, I
> guess. Would be interesting to make a profile of that and see what's
> taking so long.

I can do that if it would help. Just need instructions on how. :-)

>> Qsynth/fluidsynth used to work in the past with this configuration (I've
>> been using it for a few years at least!), so I'm not sure why it doesn't
>> work correctly anymore. :-/
> 
> It probably stopped working when we started caring about thread safety...

Ah, the days of innocence are over. ;-(

>> But I *do* know that the patch that was
>> posted to this list *does* work; apparently it just needs to be applied
>> to some other code paths (like the "reset" code).
> 
> Unfortunately it is not that simple - applying the patch as it was
> applied to the initialisation can only be done when the audio engine is
> not running in parallel. When you do a system reset, the audio can get
> calls in parallel, which ruins thread safety.
> 
> Looking into fluid_synth_system_reset in particular, it seems it might
> do some time intensive tasks in fluid_rvoice_mixer_reset_fx that could
> cause the timeout. In this case I guess we might have to move parts of
> the reverb and chorus to the non-realtime thread or something :-/

I wish I knew more about the architecture of fluidsynth so I could poke
around and see if I could fix things, but I've got too many irons in the
fire as it is right now. At any rate, having said that, take this for
what it's worth: Maybe everything that isn't directly related to pumping
sound into JACK's pipes should go into a non-realtime thread. I don't
know what kind of signaling that would require between threads, but it
seems reasonable. That is, in my naive view of things here. :-)

Warmest regards,

Shamus