Quoting David Henningsson <[email protected]>:
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
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
