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

[josh]

Quoting David Henningsson <address@hidden>:
> 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

I've noticed that jackdmp (Jack 2.0) is more resilient to these types  
of problems, since it wont timeout a client, but will instead just use  
the last audio buffer it provided.

Swami has a more efficient method of handling note-ons than the  
default FluidSynth method.  Something similar should probably be  
integrated into FluidSynth directly.  Rather than calculating all the  
instruments parameters during note-on time, a voice cache is created  
when the instrument is selected, which is a pre-calculation of all  
potential voices for an instrument.  When a note-on occurs, this table  
of voices is scanned for matches.  I imagine there are likely  
additional optimizations that could be made to quickly find matching  
voices by note number/velocity.

It would be also nice to have FluidSynth automatically adjust its  
polyphony based on CPU load.  I noticed that TiMidity++ will switch  
interpolation algorithms to less CPU intensive ones when CPU usage  
gets high.  Something like that might also be nice.

The voice stealing algorithm also needs improvement.

This sounds like it could be a good focus of the next major version of  
FluidSynth.

Regards,
Josh