[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Shamus
Subject: Re: [fluid-dev] JACK connection problems with fluidsynth
Date: Tue, 24 May 2011 17:24:13 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110420 Lightning/1.0b3pre Thunderbird/3.1.9

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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]