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

[Ebrahim Mayat]

Message to be forwarded to LAU.
> 
> Asunto: Re: [LAU] Fluidsynth, soundfonts, jack, and latency
> Fecha: Saturday, November 14, 2009
> De: Guru Prasad <address@hidden>
> Para: lau <address@hidden>
> 
> ----------  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!).

Heh, heh, heh.heh.....

Guru, you're gotta be kidding....heh, heh, heh, heh. Perhaps you could
try something more realistic: like Rachmaninoff, Liszt or even Chopin
solo pieces, maybe Paganini...or even Keith Emerson, John McLaughlin...

> 
> 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
> second.
> 
> 
> Yes, the crash corresponds to cpu usage spikes of ~50% (at least).
> 
> 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.


Well, let's not exaggerate :-) 


> 
> 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).

This sounds like a conclusion put forward by a computer programmer who
is totally ignorant of any form of musical aesthetic. Fluidsynth does
not have a disk streaming feature while linuxsampler does. This does not
impede both fluidsynth and linuxsampler to be used effectively by any
skillful performer who is cognizant of the potential of each of these
softwares. Similarly, why do some performers swear by their analog
synths while others prefer high-end digital workstations ? Each paradigm
has its own artistic value and if used effectively can serve the artist
well. Julian Bream and Jimi Hendrix were both great guitarists but each
stretched the potential of his respective instrument (guitar) sub-type
to his own characteristic heights.



> 
> Which brings me to ask: what does it mean for a subgraph to "time
out"?
> 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, 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
> situations.
> 
> Also, are there fluidsynth developers who are on this list? If not, is
there
> a better forum to give them feedback regarding these issues? Given the
> availability of decent to good soundfonts, and the number of man-hours
put
> in by various developers on applications like qsynth and ghostess, it
is
> truly unfortunate that the base fluidsynth library itself is
inherently
> unusable in live contexts.

As Pedro has suggested, we need more details about Guru's testing
conditions. Perhaps, Guru could also point us to some of his virtuoso
recordings to illustrate his point. I am all ears....and last but not
least Guru should address his concerns directly to the fluid-dev list.

E