Re: [fluid-dev] ALSA driver consuming too much CPU

[Paul Millar]

Hi  Josh,

On Sunday 19 November 2006 18:06, Josh Green wrote:
> Hallo Paul,
>
> On Thu, 2006-11-16 at 22:02 +0000, Paul Millar wrote:
> > So, in terms of documentation, would you say this is more of a problem
> > with alsa than fluidsynth?  If so, do you know if it's fixed with a 
> > particular release of asla/libasound?
>
> I think its likely a problem with the ALSA driver code in FluidSynth,

OK, I'll put this down as a bug either in fluidsynth's ALSA code, or ALSA 
itself.  I guess its still under investigation.

> > Finally, are there options that further reduce CPU usage, perhaps at the
> > cost of loosing some sound fidelity? 
>
> There are a few parameters you could play with to try and get less CPU
> consumption.  If you just wish to limit the maximum CPU consumption, the
> best option right now is setting the synth.polyphony settings value to a
> max number of voices.

OK, I've add this as an option.  Although (for me) it didn't seem to work:

fluidsynth> unable to set maxnotes (synth.polyphony) = 16

I've tried with maxnotes set to 32 and 64.  The docs say values from 16--4096 
are valid, but none seemed to work.


> The other option is to play with the interpolation algorithm selection.

 I've added this:  "linear" is pretty bad and "none" is just awful (both as 
expected).

What was strange though was they didn't seem to be contributing greatly to the 
load.  Just roughly eye-balling a CPU usage graph suggests that changing the 
interpolation doesn't affect things much.

I guess I'd have to do profiling to find out where the CPU is being used ... 
something I'll put off for a rainy day.


> If for some reason you can do without reverb and/or chorus you could
> disable them (synth.reverb.active and synth.chorus.active).

I've add these, too:  there might be people out there who can live 
without 'em.


> You could try messing with the FluidSynth sample rate
> (synth.sample-rate), but I think that really depends on if your sound
> card can support the rate you chooose, or you'll just end up with it
> having to be converted by ALSA anyways (conversion won't be done if hw:0
> is being used, it will just fail). 

OK, I should probably leave the sample rate alone.  There's currently an 
option for changing this, but I'll document it without suggesting people 
fiddle.

> Hope that gives you a better idea of what to play with.

Definitely!

Thanks,

Paul.

pgphQi8soFKF5.pgp
Description: PGP signature