[Top][All Lists]

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

Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi

From: David Henningsson
Subject: Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi
Date: Wed, 21 Nov 2012 16:26:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

On 11/21/2012 11:07 AM, Jan Newmarch wrote:

Some things are getting clearer...

First off: it's only parts of nightsin.kar that distort badly - about 20
seconds worth, in different places. The rest plays fine. The bad bits
are when CPU usage hits impossible values - "top" says 99.9% and
"pidstat" says anything upto 380%!

It isn't a universal issue:
         Files with no problems:
         Files with problems:
                 awhiters2.kar - good test, errors occur early
(Sorry, I don't know which ones are open content and which ones I

Tools that give average values over the whole song, such as "prof",
aren't helping as much as they could, because the bad behaviour is
limited to small parts. For example, the interpolation takes a lot of
CPU, but changing that to linear (interp 1) or no interpolation (interp
0) made no difference to the bad bits.


That is a very valid point; we might not strive to eliminate the average CPU as much as the worst-case CPU, even if both are important.

Maybe you could run "perf top -d 1" and monitor that, to see if anything special happens while the CPU maxes out?

The soundfonts used do not seem to affect things: memory usage is not
the issue, and there is no observable difference in sound quality
between General Sound (20% mem) and FluidR3 (40% mem).

QSynth is unusable out of the box on the RPi. It would be nice to use
it, but the sound is awful and CPU usage is up around 50% even when it
isn't playing anything! I'm testing with ALSA which is the layer below
Jack so that shouldn't be the difference.

I tried compiling with "cmake .. -Denable-floats" and without floats. No
observable difference in sound quality, so I would say that float vs
double is not the problem.

Sure. Still doing some timing to see performance gains (I got about 20% performance gain here) would be nice to know.

I have another idea too; maybe we're trashing the L1 cache? If so, running with -z 1024 or -z 512 might give better result (combined with using floats instead of doubles). Here, -z 1024 gave better results, but not by much. The Raspberry Pi does not seem to have a L2 Cache (for CPU usage), so it might diff more for you.

Okay, so what worked? First, you need the Raspbian image with FPU
support ("cat /proc/cpuinfo" shows "vfp"). Then set either of these

1) polyphony=64 and reverb=false; or
2) rate=22050

Both of these options play all of my "bad" files okay. No need for
turning chorus off. But the peak CPU usage at the bad bits is still
hitting 80-99%, while the average usage is about 45%.  With the "good"
files, CPU usage stays in the range 20-60%.

But that sounds like it makes sense, right? With half the sample rate, CPU usage is about half too?

So I still don't know what
is the cause of the high CPU, but maybe this will help.

If we do an extremely rough calculation: We have a computer of 1 GHz, a sample rate of 50 kHz, and 100 voices; that gives us only 200 cycles per voice and sample. And we still have to do several floating point calculations every sample. So this leads me to believe that maybe there is no holy grail solution to this problem, nothing obvious we're missing that causes this CPU usage. Maybe it's more of trying one thing here and another thing there.

NEON optimisation, anyone?

// David

reply via email to

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