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

[Jan Newmarch]

On Wed, 2012-11-21 at 16:26 +0100, David Henningsson wrote:

> 
> 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?

No luck :-(. The output looked the same for good and bad bits

> 
> 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.

Just setting -z to either 512 or 1024 and floats instead of doubles
didn't work by itself.

> 
> 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.

Sorry to pull in the "competition" here... Timidity gives CPU usage of
around 70-90% on nightsin.kar. But it doesn't have the blowouts to above
100%, and plays okay (just). I don't know what the default settings are
for Timidity though. Maybe it is just fine tuning, although Aere is
getting good results on a slower CPU.

On another tangent, running Fluidsynth as a server to the ALSA MIDI
sequencer alsa_seq plays okay with rate set to 22050.

-- 
Dr Jan Newmarch
Head of ICT and Commerce (Higher Education)

P 61 3 9286 9971
M +61 4 0117 0509
F 61 3 9286 9100
W www.boxhill.edu.au
W jan.newmarch.name
E address@hidden
E address@hidden