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.