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

[David Henningsson]

On 11/21/2012 11:07 AM, Jan Newmarch wrote:
> Hi
>
> 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:
>                  Salsa.mid
>                  blowini.kar
>          Files with problems:
>                  andwheni.kar
>                  awhiters2.kar - good test, errors occur early
>                  moneymon.kar
>                  ifeeltheearthmove.kar
> (Sorry, I don't know which ones are open content and which ones I
> bought.)
>
> 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.

Ok.

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
> options:
>
> 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