Great feedback, thanks!

> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 30 May 2018 08:54:19 +0200
> From: Marcus Weseloh <mar...@weseloh.cc>
> To: FluidSynth mailing list <fluid-dev@nongnu.org>
> Subject: Re: [fluid-dev] Raspbian / Pi Zero - force hard float
>         compile?
> Message-ID:
>         <CAGNoLaOrzW8Qg=YmwOsbexmyimq5pXkvgE4j+asQ0BvjRv6Z6g@mail.
> gmail.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
>
>
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev

Reply via email to