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

[jean-jacques.ceresa]

Hi,
>Le 26/04/2016 17:34, Element Green a écrit :
>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.  It seems those Raspberry Pi boards have quad cores?  So you could pass "-o >synth.cpu-cores=4".

Just to confirm that "synth.cpu-cores" setting work well. This has been verified on others boards (unfortnately not yet on Raspberry Pi boards !).
Examples of performance measurement follows below:
1) Pentium(R) 4 CPU 1.70 Ghz (1 core): fluidsynth can play 218 voices (100 % cpu)
2) Pentium(R) 4 CPU 2.40 Ghz (1 core): fluidsynth can play 336 voices (100 % cpu)
3.1) AMD Phenom II x 4 955 (4 core): fluidsynth (synth.cpu-cores=1)  can play 745 voices (100 % cpu)

3.2) AMD Phenom II x 4 955 (4 core): fluidsynth (synth.cpu-cores=2)  can play 1491 voices (100 % cpu)
3.3) AMD Phenom II x 4 955 (4 core): fluidsynth (synth.cpu-cores=3)  can play 2319voices (100 % cpu)
3.4) AMD Phenom II x 4 955 (4 core): fluidsynth (synth.cpu-cores=4)  can play 3015voices (100 % cpu)

Performance measurement has be done with this patch:  http://lists.nongnu.org/archive/html/fluid-dev/2016-02/msg00009.html
It worth to extract "performance measurement" for others boards (Raspberry ,...) and share theses informations.

>Le 26/04/2016 17:34, Element Green a écrit :

>So you may want to make sure that FluidSynth is actually built with hardware floating point support.

That is true that compilers options are important !

As an example for the same hardware (point (2) above: Pentium(R) 4 CPU 2.40 Ghz)
- (a) using VS studio 6 and running on Windows XP: fluidSynth can play 336 voices max.

- (b) using gcc and running on linux Debian: fluidSynth can play 264voices max.
Actually i don't know why case (b) is 21 % less performant than case (a) but i suspect compilers options.

Best regards,

Le 26/04/2016 17:34, Element Green a écrit :

Just wanted to follow up with some info on FPU support for that system.  It sounds like the Raspberry Pi does have hardware FPU support.  However, it may be that FluidSynth has not been compiled with it.  From the 2nd stackexchange answer (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

So you may want to make sure that FluidSynth is actually built with hardware floating point support.

Best regards,

Element

On Tue, Apr 26, 2016 at 9:17 AM, Element Green <address@hidden> wrote:

Hello,

On Tue, Apr 26, 2016 at 2:25 AM, R.L. Horn <address@hidden> wrote:

On Fri, 22 Apr 2016, Maciej - filologia angielska wrote:

2. Today I noticed that the problem must be due to Raspberry Pi's limitations in terms of its computing power.

Fluidsynth, it has to be said, is a bit of a CPU hog.  Unfortunately, I believe the only way to boost performance is by using boards with more processors, which fluidsynth doesn't take advantage of.

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.  It seems those Raspberry Pi boards have quad cores?  So you could pass "-o synth.cpu-cores=4".  However, from a quick glance of the specs of those boards, it isn't apparent as to whether it has an FPU.  If it does not have an FPU then you will get horrible performance, since all the floating point math that FluidSynth is based on will be emulated in software.

fluidsynth -C0 -R0 -r22050 -l -a alsa -o audio.alsa.device=plughw:0

An HW: device would probably be faster (at least you don't have resamplers on top of resamplers), but latency is often a problem.

Then I increased the -r to 44100 and subsequently to 48000. With each increase, the Rpi would encounter "funny noises/drop-outs" (I do not know how to call them) and eventually the machine would crash during some of the more complex parts of the MID song.

That's not supposed to happen: you shouldn't get an EIO unless something really serious goes wrong.  It sort of sounds like the driver simply gives up after X number of under-runs.

I suspect the same thing.  Something is likely wrong with the driver in regards to underruns.

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

Best regards,

Element Green

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev