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

[Josh Green]

Hallo Paul,

On Thu, 2006-11-16 at 22:02 +0000, Paul Millar wrote:
> Josh, Garett,
> 
> Thank guys for the quick reply.
> 
> Yes, the work-around worked fine:  when setting "audio.alsa.device" to "hw:0" 
> I see the CPU usage drops to far more modest values.  
> Setting "audio.alsa.device" to "default" (fluidsynth's default value, I 
> believe) recreates the problem.  [as an aside, for me, this has nothing to do 
> with running as root.]
> 
> I now set "hw:0" as a default (within monami), but allowed users to override 
> it with an "alsadevice" monami option.  This should be fine, just needs 
> documenting.
> 
> 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,
since other software doesn't seem to have this same problem with the
default audio device (which these days I believe is the ALSA plug stuff
by default), although there is a chance that it could be an ALSA bug
too, that happens to be getting tripped by something specific that
FluidSynth is doing.  I have not yet done any in depth investigations,
but this problem is on the top of my FluidSynth task list.  I think I'll
likely just find some good ALSA driver code and replace the existing
implementation in FluidSynth to see if that improves things.

> Finally, are there options that further reduce CPU usage, perhaps at the cost 
> of loosing some sound fidelity?  I'd guess setting the audio output to 8-bit 
> mono, dropping the sample frequency would take less CPU, but I can't seem to 
> get the alsa driver to accept any of these options. [*]
> 

I don't think changing the ALSA settings will matter, in fact it could
make it worse (if the format has to be converted).  When using the hw:0
device, there are more limitations on what sample formats can be used,
since it's talking more directly with the audio interface.  That is what
the plug architecture is for in ALSA, it does automatic conversion on
the fly for audio formats.  FluidSynth does most of its synthesis using
floating point numbers and then converts the final result to whatever
audio output format is being used (16 bit or 32 bit floats).

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.  The voice stealing algorithm still needs some
work though (some annoying side effects may result when maximum number
of voices is reached, such as a recently played note being terminated).

The other option is to play with the interpolation algorithm selection.
You can do this with the "interp" command or "interpc" for a single MIDI
channel.  The current options seem to be 0 (no interpolation), 1
(linear), 4 (default/4th order), 7 (7th order).

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

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).  Also note that currently it is
possible for FluidSynth to use a different internal rate as the sound
card, which results in an out of tune situation.

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

> Cheers,
> 
> Paul.
> 
> [*]  I'm getting some weird errors and warnings when trying to set these.  
> The 
> docs say audio.periods is limited to 2--64, but alsa (for me, at least) seems 
> to have 65 as a lower limit.  I can't seem to set either audio.period-size 
> nor audio.periods to explicit values: fluid_settings_setstr() always seems to 
> fail.  For example:
> 
> fluidsynth> unable to set bufsize (audio.period-size) = 1000
> fluidsynth> unable to set bufcount (audio.periods) = 65
> fluidsynth> The sample rate is set to 44100, the synthesizer may be out of 
> tune
> fluidsynth> Requested a period size of 64, got 65 instead
> fluidsynth> ALSA driver: Using format s16, rw, interleaved
> 

Wow!  Not sure what is going on there, but 65 periods is quite a lot.  I
suspect there is something wrong with the FluidSynth code for the ALSA
driver.  I would try something like (2048, 1024, 512, 256, 128, 64) for
the period size and (2, 3, 4, 5, etc) for the number of periods.  Of
course the lower the numbers the less latency, and more possibility of
an underrun (clicks in audio output), which is improved when running at
FIFO scheduling (usually requires root privileges).  The hw:0 interface
is rather picky about the format, as I mentioned above.  It likely
depends on what your card can actually do.

> The "sample rate is set to 44100" warning is weird.  Although it doesn't say 
> it above, I'm asking for 44.1kHz sample rate, so it shouldn't really be 
> warning me here ... or am I missing something?
> 

Sounds like FluidSynth is using a different rate than ALSA is, which
will indeed result in an out of tune situation.  Does your sound card
support 44100?

Best regards,
        Josh Green