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

[Aere Greenway]

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 <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: 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 <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: 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
> 
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev


-- 

Sincerely,
AereSincerely,
Aere

Sincerely,
Aere