fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] FluidSynth on Raspberry Pi with Wolfson Pi card


From: R.L. Horn
Subject: Re: [fluid-dev] FluidSynth on Raspberry Pi with Wolfson Pi card
Date: Wed, 27 Apr 2016 03:08:59 -0500 (CDT)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

On Tue, 26 Apr 2016, Element Green wrote:

Actually that is not true, in regards to FluidSynth utilizing multiple
CPUs.  It can do exactly that, you just have to tell it to by setting
synth.cpu-cores.

Oops...that completely slipped my mind.

Later:

http://raspberrypi.stackexchange.com/questions/545/does-the-raspberry-pi-have-hardware-floating-point-support)
I found the following CFLAGS mentioned for this:
-mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard

A lot of information on Stack Exchange looks to be a bit out-of-date. Current RPi 2 and 3 boards have quad-core ARMv7 and v8 CPUs, respectively, so plenty of horsepower there.

AFAIK, all RPi versions have had hardware FP but I'm not certain that it's, even now, supported by Raspbian. Other distributions have FPU support with the relevant GCC defaults, or so I gather.

ARM FPU support was a mess generally, and the float-abi option seems to reflect that. According to the GCC documentation:

  `-mfloat-abi=NAME'
       Specifies which floating-point ABI to use.  Permissible values
       are: `soft', `softfp' and `hard'.

       Specifying `soft' causes GCC to generate output containing library
       calls for floating-point operations.  `softfp' allows the
       generation of code using hardware floating-point instructions, but
       still uses the soft-float calling conventions.  `hard' allows
       generation of floating-point instructions and uses FPU-specific
       calling conventions.

       The default depends on the specific target configuration.  Note
       that the hard-float and soft-float ABIs are not link-compatible;
       you must compile your entire program with the same ABI, and link
       with a compatible set of libraries.

So it looks like *all* of fluidsynth's dependencies, or at least those with FP functions, would also have to be rebuilt.

Hopefully someone who knows the architecture can chime in and let us know how -- or if -- the link-time mess is resolved.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]