Hi,
>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 wanted to confirm that multi-cores settings ("synth.cpu-cores")
work very well. I have already verify this on others boards
(unfortunately not on Raspberry Pi boards!).
For example with thoses CPU, results are the following:
1) Pentium(R) CPU 1.70 Ghz (1 core), fluidsynth can play 218
simultaneous voices (at 100% cpu load).
2) Pentium(R) CPU 2.40 Ghz (1 core), fluidsynth can play 336 voices
(at 100% cpu load).
3.1)AMD Phenom II x 4 955 (4 cores) with synth.cpu-cores=1, fluidsynth
can play 745 simultaneous voices (at 100% cpu load).
3.2)AMD Phenom II x 4 955 (4 cores) with synth.cpu-cores=2, fluidsynth
can play 1491 simultaneous voices (at 100% cpu load).
3.3)AMD Phenom II x 4 955 (4 cores) with synth.cpu-cores=3, fluidsynth
can play 2319 simultaneous voices (at 100% cpu load).
3.4)AMD Phenom II x 4 955 (4 cores) with synth.cpu-cores=4, fluidsynth
can play 3015 simultaneous voices (at 100% cpu load).
To get performance measurement, this patch can be useful:
http://lists.nongnu.org/archive/html/fluid-dev/2016-02/msg00009.html
It will help to extract performance capabilities of others boards like "
Raspberry".
Also, it worth to share theses informations.
>Element Green a écrit :
>So you may want to make sure that FluidSynth is actually built with
hardware floating point support.
It is true that compilers options are important !!
As an example, actually for the same hardware (example (2) above:
Pentium(R) CPU 2.40 Ghz )
- (a) when build with visual studio 6 and running on Windows XP:
fluidsynth can play 336 voices max.
- (b) when build with gcc and running on linux Debian: fluidsynth can
play 264 voices max.
Actually i don'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
<elem...@elementsofsound.org <mailto:elem...@elementsofsound.org>> wrote:
Hello,
On Tue, Apr 26, 2016 at 2:25 AM, R.L. Horn <li...@eastcheap.org
<mailto:li...@eastcheap.org>> 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
fluid-dev@nongnu.org <mailto:fluid-dev@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/fluid-dev
Best regards,
Element Green
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
