[Top][All Lists]

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

Re: [fluid-dev] Multiple jack clients == really bad

From: josh
Subject: Re: [fluid-dev] Multiple jack clients == really bad
Date: Sat, 17 Oct 2009 12:38:20 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Quoting David Henningsson <address@hidden>:
address@hidden wrote:
While doing some testing of the MIDI parser, using the Jack MIDI driver, I discovered that FluidSynth would semi-randomly lose connection with Jack on startup.

Seems bad. I guess most people with Jack use the ALSA MIDI drivers, right?

At this point, that is probably the case. JACK MIDI does sound like a good direction though, synchronous audio and MIDI is nice :)

I noticed that jack_client_new() is deprecated in favor of jack_client_open(), so I've switched to that and will add audio.jack.server and midi.jack.server parameters.

It seems Jack (at least 116.1) doesn't like to have multiple client connections. Currently the Jack audio driver and Jack MIDI driver create separate client connections. In addition, I discovered that PortAudio will also create a Jack client connection when you initialize the library. In order to have the list of PortAudio devices in the audio.portaudio.device, PortAudio is initialized even if it doesn't get used. We may be able to get around this by de-initializing the driver at the end of getting the device list.

If it is causing trouble for more people than it solves problems for;
we could consider disabling the PortAudio driver by default (i e people
have to provide a configure switch to enable PortAudio).

I terminate the PulseAudio connection now after the device list is read, hopefully that improves things.

With the help of jackd verbose output, I discovered that fluidsynth is getting disconnected because of a timeout. I increased the jackd timeout and found that the fluidsynth disconnect issue went away. I put some timing metric code in the Jack callback though and saw that it was only like 4ms or so of delay, so the actual callback processing doesn't seem to be the factor that is causing a delay of over the default of 500ms. I'm going to try updating my Jack version to see if that fixes anything.

At any rate, some work cut out for me, to merge the JACK audio and MIDI drivers. I already kind of hacked it somewhat, but its a bit too messy for my taste.

Yet another status report, as we count down to the release of 1.1.0. Any reports on testing would be greatly appreciated. I'm trying to test as much as I can, but its hard to cover every usage scenario.

From what I've tested it looks fine. Either that, or I try to fix it ;-)

Cool! So at least its working for you ;) I suppose if worse comes to worse, 1.1.0 will be a testing release, ha ha, but I don't like doing things that way.

// David


reply via email to

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