Geoff:
I am able to run fluidsynth (via the QSynth GUI) on a 450 megahertz,
single processor (Pentium 3) machine, running Lubuntu 18.04. That
machine has hardware floating-point capability.
To make QSynth/Fluidsynth work on that machine, I set polyphony to 48,
and turn-off Chorus. On other (faster, but still slower than modern
machines), I set Polyphony to 64, and (depending on how slow it is)
turn-off Chorus.
Setup that way, it will play very demanding MIDI files (using the
Rosegarden sequence editor) without any audio underruns.
- Aere
On 05/30/2018 12:54 AM, Marcus Weseloh wrote:
Hi Geoff,
you seem to be fine on the hard-float front, at least where FluidSynth
is concerned. The armv6l in the uname output *might* be an indicator
that the system as a whole has been compiled with soft-float, but that
could be wrong. uname output can be set arbitrarily, best to check a
few other executables from your distro.
Your platform is not very powerful, so you can't expect too much from
running FluidSynth on it.
There are a few compile time tweaks you can try (cmake options):
- Make sure you are using the "Release" build type:
-DCMAKE_BUILD_TYPE=Release
- Use optimisation flags --fffast-math and maybe also -O3:
-DCMAKE_C_FLAGS_RELEASE="--ffast-math -O3"
- use float instead of double for maths in Fluidsynth: -enable-floats=true
Then you would have to decide what you want to optimise for:
1. Low latency
2. High polyphony
Pick one, you can't have both. At least not on your hardware.
If you don't care about latency at all (i.e you are simply rendering
audio and don't mind waiting a few seconds until the whole song has
been rendered), you can use fast-render to file:
fluidsynth -F output.wav ...
In all other cases you will need to limit the polyphony (number of
simultaneous voices that FluidSynth can render). FluidSynth's default
of 256 is probably way too high for your platform. You could start by
reducing the polyphony until you don't experience any issues anymore,
then increase it again slightly. But leave it a little safety margin:
fluidsynth -o synth.polyphony=128 ...
If you want to go for really low latency, you will need to use a
custom kernel with something like the preempt-rt patches applied. Then
hand-tweak your IRQ latencies, decrease the polyphony to something in
the region of 40-60 and reduce the buffer size and buffer count used
by FluidSynth to the lowest levels your audio driver supports. I'm
running FluidSynth on similar (but slightly more powerful) hardware
and can achieve very low latency using this kind of setup. It takes
quite a bit of work getting everything tuned right, but it is possible.
If you don't care about high latency but still want "real time"
playback, then you can try increasing the buffer size and buffer
counts used by FluidSynth (see fluidsynth --help, I can't remember the
switches at the moment).
And if you don't need chrous or reverb effects, switch them off (-R0
and -C0)
If you were on a platform with multiple cores, you could use the
parallel-rendering mode of FluidSynth. But your CPU only has one
core, so that is not an option.
In real-time playback situations, keeping FluidSynth happy with the
polyphony limit is the most important bit. As soon as it gets into an
overflow situation and audio output starts to break, it does take
quite some time for it to get back on track, at least in my
experience. So avoid that situation at all costs, by reducing
polyphony to safe levels.
Long story short: I think you can get FluidSynth to work reasonably
well even on your platform, it all depends on what you want to
achieve. And upgrading to a RPi 3+ would definitely make everything a
lot easier! :-)
Cheers,
Marcus
compile FluidSynth with "--ffast-math" and maybe also "-O3" compile
time options:
cmake .. -D
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
--
Sincerely,
Aere
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
