Quoting David Henningsson <launchpad.web@xxxxxxxxxxxxxx>:
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
David, this appears to be a reasonable summary. It does appear that the issue is not solely with fluidsynth, but the way fluidsynth and jack integrate with one another. Are such shortcomings inevitable in the "do 1 thing but do it well" philosophy of linux apps (I hope not!) ? For instance, it does appear unlikely that this would happen in an 'all-purpose' applicaton like Apple's Logic Pro, for example...
This sounds like it could be a good focus of the next major version of FluidSynth.
And thanks, Pedro, for forwarding my message to the fluid-dev list. I'd be happy if constructive improvements follow as a consequence!
I will perform the stress test under the standardized/simplified conditions that you describe, and get back to you. More about that in the next post....
Cheers,
Guru
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
