|
| From: | Geoff Plitt |
| Subject: | Re: [fluid-dev] Raspbian / Pi Zero - force hard float compile? |
| Date: | Wed, 30 May 2018 19:07:42 -0700 |
Great feedback, thanks!------------------------------------------------------------ ----------
Message: 1
Date: Wed, 30 May 2018 08:54:19 +0200
From: Marcus Weseloh <address@hidden>
To: FluidSynth mailing list <address@hidden>
Subject: Re: [fluid-dev] Raspbian / Pi Zero - force hard float
compile?
Message-ID:
<CAGNoLaOrzW8Qg=YmwOsbexmyimq5address@hidden >ail.com
Content-Type: text/plain; charset="utf-8"
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
| [Prev in Thread] | Current Thread | [Next in Thread] |