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