[Top][All Lists]

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

Re: [fluid-dev] Fwd: Re: [LAU] Fluidsynth, soundfonts, jack, and latenc

From: David Henningsson
Subject: Re: [fluid-dev] Fwd: Re: [LAU] Fluidsynth, soundfonts, jack, and latency
Date: Sat, 14 Nov 2009 23:42:12 +0100
User-agent: Thunderbird (X11/20090817)

Pedro Lopez-Cabanillas wrote:
----------  Forwarded Message  ----------

Asunto: Re: [LAU] Fluidsynth, soundfonts, jack, and latency
Fecha: Saturday, November 14, 2009
De: Guru Prasad <address@hidden>
Para: lau <address@hidden>

Hello everyone,
  Finally! Here's a quick update on my fluidsynth issues.
I figured there has to be a better way of stress testing the system than
physically banging my midi controller. I created a simple file in rosegarden
, equivalent of hitting 88(?)keys repeatedly in a loop, with the sustain
pedal on; I've attached the rosegarden file. It would be nice if people
could post results of using this file (or a more suitable one!).

Here are some of the initial (and very interesting) results (core 2 macbook
running AVLinux):
Using 2 qsynth engines, each containting multiple soundfonts (around ~200
MB), at higher speeds (above 360 BPM), fluidsynth (qsynth in this case)
crashes with this error in the qjackctl messages window:

subgraph starting at qsynth timed out (subgraph_wait_fd=32, status = 0,
state = Finished, pollret = 0 revents = 0x0)

Sometimes, not just qsynth, but other applications, such as jack-rack or
rosegarden also crash with the same error.

So not only does fluidsynth itself crash, it can potentially drag down the
whole ship with it!

To answer Lee's question, yes and no. Most of the times, I can restart the
qsynth engines and everything's back to normal, but occasionally, I have to
restart jackd itself.

For some soundfonts (including my "bread and butter" ones :( ), running the
loop at 720 BPM guarantees an (almost) instant crash, within around a

Yes, the crash corresponds to cpu usage spikes of ~50% (at least).

Whereas 50% on a core 2 CPU probably means 100% on one CPU and the other one almost idling?

Of course, the stress test is unreasonably demanding, but eventually, that
kind of extreme stress will be encountered. For a live musician, an
application that cannot deal with it is simply unreliable. Bottomline: Using
soundfonts on linux system for a live performance is a bad idea.

On the other hand, I ran the same thing against ~900 MB piano sample on
Linuxsampler. Perfectly stable at 720 BPM.
Of course, I can't percieve dropped notes, and there are no xruns reported,
but still.. it doesn't crash!!! (This ties in with Dominic's observation of
'better' performance of LInuxsampler vis-a-vis Fluidsynth).

Which brings me to ask: what does it mean for a subgraph to "time out"?

I believe it means that jack calls fluidsynth to perform audio rendering, but that call does not return in time.

Understandably, a given audio application can't be expected to perform under
any cpu load. But why can't fluidsynth just drop notes and move on? Are
there any simple workarounds for subgraphs timing out,

Basically; I would say the easiest way would be to increase jack's timeout and/or reduce fluidsynth's polyphony. However, currently FluidSynth has limited protection against a massive amount of MIDI events (there is some, but it can certainly be improved).

or is it an inherent
bug in the fluidsynth libraries? The strong feeling that one gets is that
fluidsynth has simply not been designed with failsafes in mind, for extreme

Fluidsynth has many use cases, both realtime and non-realtime. That is not an excuse for not having failsafes, just that it's easy to forget one of the extreme situations sometimes.

Also, are there fluidsynth developers who are on this list? If not, is there
a better forum to give them feedback regarding these issues?

The fluid-dev list, which your message was forwarded to.

(P.S. I do hope I'm not jumping to conclusions here. If someone can show
that the problem lies not with fluidsynth but some other application, I'd be
happy to be corrected. But that there is a serious problem somewhere, there
is little doubt!)

Well, a search for "subgraph starting at" "timed out" at google shows many applications timing out, not just FluidSynth. I do think jack can handle things better as well.

So to sum this up I think there is not one scapegoat here, but many:

1) FluidSynth could have better protection against many notes starting at the same time, but that requires some redesign unfortunately

2) Jack could handle timing errors better, so things do not crash when it happens

3) You could configure fluidsynth's polyphony to limit FluidSynth's CPU usage

// David

reply via email to

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