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