Jan:
Given your attempts, which proved to be unsuccessful, it puzzled me how
it worked for me on an even slower (450 megahertz) machine, but didn't
work for me.
I checked my slow processor (a 450-megahertz HP Vectra) using the system
profiler (Linux, Lubuntu 12.10), and it shows that my machine does have
a floating-point-unit (math co-processor, implemented in hardware).
>From what others have said, that particular difference may well be what
made it work for me.
Other than that, there are a few other differences that may (or may not)
be relevant.
1. I use the Lubuntu variant of Ubuntu Linux, which has much lower
overhead than Ubuntu.
2. I use Qsynth, which makes it easy to configure the polyphony
parameter, and also to turn-off the "chorus" and "reverb" features
(which also significantly reduces overhead).
3. The audio output of Qsynth (which uses libfluidsynth1) goes through
the JACK audio connection kit, using qjackctl.
There is yet one other thing that might be relevant, and perhaps David
can comment on it.
I'm using David Henningson's PPA of a pre-release of the 1.1.6 version
of libfluidsynth1, rather than the actual release version of 1.1.6. I
use this because the version of fluidsynth that comes out with the
Ubuntu distribution has significant problems to the extent of not being
able to successfully play my demo-pieces.
However, before 1.1.6 was released, I tested the release version of
it.
Initially, this version did not work on my 450 megahertz machine. David
did something to it, and had me re-test it, and it worked this second
time. And as far as I know, the version that was released had this
final change in it. But I never tested the actual release version. And
maybe, if you compile the code yourself, you don't get this change.
I wonder if the version you generated does not have this final change in
it, that David put in.
Perhaps David can explain this final change he put in that made such a
significant difference.
- Aere
-----Original Message-----
From: Jan Newmarch <j...@newmarch.name>
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: Tue, 20 Nov 2012 18:58:36 +1100
Hi
I recompiled 1.1.6 with polyphony set to 64. There doesn't seem to be a
command line option to reset parameters like this, but it shouldn't be
too hard to add one. Yes I know, use fluid_settings_setXXX in the code...
Anyway... no better. Still hits CPU above 99% (!) and distorts
accordingly.
(The pidstat command I used was
pidtat -C fluidsynth - u -r 5
for 5 second periods.)
David gives perf figures of
30% - fluid_rvoice_dsp_interpolate_4th_order
27% - fluid_rvoice_buffers_mix
13% - fluid_iir_filter_apply
9% - fluid_revmodel_processmix
I ran perf (from linux-tools Debian pkg) on the RPi for nightsin.kar using two
soundfonts and got
32.07% fluid_rvoice_buffers_mix
26.89% fluid_rvoice_dsp_interpolate_4th_order
12.99% fluid_iir_filter_apply
11.00% fluid_revmodel_processmi
for the FluidR3_Gm and
29.49% fluid_rvoice_buffers_mix
23.71% fluid_rvoice_dsp_interpolate_4th_order
14.89% fluid_revmodel_processmix
12.53% fluid_iir_filter_apply
for the GeneralUser soundfont (which sounds a bit better).
No significant difference.
Jan
--
On Sun, 2012-11-18 at 08:31 -0700, Aere Greenway wrote:
> Jan & David:
>
> In my opinion, limiting the polyphony (I presume that is what you mean
> by "limiting the voices") does not adversely affect the sound.
>
> What is using up the CPU, is voices still being 'sounded' that have
> long before faded to where they are inaudible. sysstat
>
> If Fluidsynth works similarly to the EMU10K1/2 (Soundblaster & Audigy)
> chip, it should 'take-out' the oldest voices first, though I don't
> know if that is actually the case.
>
> I think the Soundblaster and Audigy soundcards have a polyphony limit
> of 64 (I have also heard that the limit is actually 48). And since
> the pieces sounded fine on my Soundblaster card, I tried setting the
> polyphony to 64, and it also sounded perfectly good, and cut down the
> processor load significantly.
>
> Trying that worked fine, with no detectable degradation in sound.
>
> Since I use Qsynth, I change this by changing the "Polyphony"
> parameter of the "Audio" tab (visible after clicking the "Setup"
> button. I do not know how to make the same change using command-line
> parameters.
>
>
> - 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: Sun, 18 Nov 2012 12:51:58 +0100
>
> On 11/18/2012 11:07 AM, Jan Newmarch wrote:
> > Thanks to Christian and Aere. Here are some more results on a file
> > nightsin.kar of various choices using pidstat:
> >
> > Version flags sound font cpu % memory % comments
> > 1.1.5 none FluidR3_GM 75% 43% unlistenable
> > 1.1.5 -z 4096 FluidR3_GM 70% 43% unlistenable
> > 1.1.5 -z 4096 GeneralUser 76% 20% unlistenable
> > 1.1.6 none FluidR3_GM 80% 40% still distorting
> > 1.1.6 -z 4096 FluidR3_GM 75% 40% distorts when
> > usage > 90%
> > 1.1.6 -z 4096 GeneralUser 65% none shown
> > distorts when usage > 90%
>
> Thanks for providing a good test case. I'm not familiar with pidstat -
> could you state the command line do you use for this, for an accurate
> comparison?
>
> It looks like the CPU % maybe does not differ that much.
>
> Actually, I recently got hold of a Nexus 7 running Ubuntu [1], which has
> a Tegra 3 core. When running NIGHTSIN.KAR (found at [2]), it does indeed
> use a lot of CPU. It runs fine for the most part, but occasionally
> breaks up. (This is with -z 4096.)
>
> Running a quick perf analysis of it, the top CPU using functions are:
>
> 30% - fluid_rvoice_dsp_interpolate_4th_order
> 27% - fluid_rvoice_buffers_mix
> 13% - fluid_iir_filter_apply
> 9% - fluid_revmodel_processmix
>
> The interpolation can be reduced, but only inside the shell it seems
> like, so that would help some (at the expense of quality, as usual).
>
> Reducing the number of voices would be the first thing to try IMO, that
> is usually not that hearable hopefully.
>
> But this is indeed an interesting optimisation problem. At least
> fluid_rvoice_buffers_mix should be able to run faster I believe. I'll do
> some experiments with it when I have some more time.
>
> // David
>
> [1] https://wiki.ubuntu.com/Nexus7
>
> [2] http://www.swissdom.cc/midis/karaoke-internacional-1/n/
>
> _______________________________________________
> fluid-dev mailing list
> fluid-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
> _______________________________________________
> 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
