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

[Aere Greenway]

Jan and David:

If the "nightsin.kar" piece is "Nights in White Satin" (by The Moody Blues), the piece probably makes use of the pitch-bender extensively, in certain limited sections.  Those sections may very well be the "bad spots".  

If you watch a dump of output from a MIDI interface, even a fast-notes section has a moderate rate of output.  But when you hit the pitch-bend controller, the data comes 'blasting' out of the interface.  

Perhaps also, the act of doing the pitch-bend may involve more floating-point calculations (I am merely speculating on this point).  

It is also interesting that you prefer to keep the "chorus" control active, but will turn-off the "Reverb" control.  

I usually do just the opposite.  Most of my pieces are ensembles of individual instruments anyway, so artificially making it sound like a larger ensemble is to me, not that useful.  It also seemed to me that turning-off "chorus" made a bigger difference.  

The "reverb" effect lets your piece sound like it's in some sort of performance hall (rather than in a small room), which I think, improves the sound, so I leave it on unless I'm really hurting for reducing processor load.  

On my 450 megahertz machine, I have no choice, and I always turn off both.  

Regardless the speed of the machine, I always set the polyphony parameter to 64 (or 48 if I'm really hurting for processor-load reduction).  

I don't think I have ever observed any improvement in sound by setting polyphony to 256.  If any of you have an example of where it improves the sound, I am interested to learn.  

- Aere

-----Original Message-----
From: David Henningsson <address@hidden>
Reply-to: FluidSynth mailing list <address@hidden>
To: FluidSynth mailing list <address@hidden>
Subject: Re: [fluid-dev] problems with fluidsynth 1.1.6 on a raspberry pi
Date: Wed, 21 Nov 2012 16:26:45 +0100

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


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

-- 

Sincerely,
AereSincerely,
Aere

Sincerely,
Aere