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 <di...@ubuntu.com>
Reply-to: FluidSynth mailing list <fluid-dev@nongnu.org>
To: FluidSynth mailing list <fluid-dev@nongnu.org>
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
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
--
Sincerely,
AereSincerely,
Aere
Sincerely,
Aere
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
