Back when I used to have a 450 MHz machine, I remember avoiding
softsynths in general for the same reason. If you wanted to do music
production on such a machine, you really had to use hardware synths,
whether the sounds from a Sound Blaster AWE32 or an external unit
connected via MIDI.
-~Chris
On 11/24/2012 11:28 PM, Aere Greenway
wrote:
All:
I wouldn't characterize the test results on my 450 megahertz
machine as "good results". I would call it "just barely usable"
results.
Although I can play my demo pieces on it, and it sounds good, it
occasionally cuts-out (under-runs).
Timidity does seem to be less prone to cut-out, but it has way too
much latency to perform with. Of course, if you are just playing
an already-performed sequence, the latency wouldn't matter.
- Aere
-----Original Message-----
From: Jan Newmarch <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: Sat, 24 Nov 2012 12:27:44 +1100
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.
--
Sincerely,
Aere
Sincerely,
Aere
_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev
|