[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: Sun, 25 Nov 2012 22:05:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 11/24/2012 02:27 AM, Jan Newmarch wrote:
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

Ok. This could also mean that the stuff that takes time in "good" situations is also what takes time in "bad" situation.

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.

Ok. Let's ditch that idea then.

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.

It could be Timidity has some kind of self regulator mechanism too. But I'm not sure how comparable the two are (e g, how accurate Timidity is when it comes to rendering soundfonts).

Maybe it is just fine tuning, although Aere is
getting good results on a slower CPU.

Actually I read [1] that Raspberry Pi would be comparable to a 300 MHz Pentium 2, so probably the Pi is slightly slower than Aare's 450 MHz machine.

// David

[1] http://www.raspberrypi.org/faqs

reply via email to

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