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