Re: [fluid-dev] Re: What is the best way start fluidsynth with zero/low latency? (Louis B.)

[josh]

Quoting Pedro Lopez-Cabanillas <address@hidden>:
> On Monday, May 25, 2009, address@hidden wrote:
> > Quoting Pedro Lopez-Cabanillas <address@hidden>:
> > > On Saturday, May 23, 2009, Louis B. wrote:
> > >> Thanks for the info. I have just update the wiki with information on
> > >> how to run fluid on a netbook. see
> > >> http://fluidsynth.resonance.org/trac/wiki/LowLatency. Please correct
> > >> it if it is wrong or you want to add anything else.
> > >
> > > "Also halving the sample rate with the flag '-r22050' helps a lot."
> > >
> > > I doubt the above advice would be beneficial for latency. On the
> > > contrary, running FluidSynth with a native sound card sample rate will
> > > give the better results, because reducing the sample rate requires ALSA
> > > to perform software interpolation (by the plughw: layer) to transform the
> > > buffers into the native frequency before sending it to the hardware. This
> > > requires larger buffers and consumes CPU cycles. On the other hand, using
> > > the native frequency allows you to use the hw: interface directly.
> > >
> > > By the way, which netbook are we talking about? Which Linux distro?
> > >
> > > Regards,
> > > Pedro
> >
> > If the system is running out of CPU and the sound card actually works
> > with 22050 natively, then it could help reduce CPU usage, thus
> > preventing CPU starvation.  Another idea is to decrease
> > synth.polyphony in that case though.
>
> Louis said that he is using an eeepc 901. According to my sources this device
> has an integrated Intel HDA sound card:
> http://array.org/ubuntu/status.html?model=eeepc-901
>
> The HDA cards allow only a very restricted set of native sample rates,
> typically only above 44.1 KHz, so I found very improbable that sr=22050 is
> natively supported. This can be verified compiling and running the attached
> program. Here are some results obtained on my Asus laptop:
>
> $ ./alsa-rate
> supported sample rates for hw:0,0 : min=44100, max=192000
> $ ./alsa-rate dmix
> supported sample rates for dmix : min=48000, max=48000
> $ ./alsa-rate plughw
> supported sample rates for plughw : min=4000, max=4294967295
> $ ./alsa-rate default
> supported sample rates for default : min=4000, max=4294967295
>
> Note that "dmix", "plughw" and "default" are not native, they are software
> conversion layers.
>
> Regards,
> Pedro


It seems what we have both been pointing out, is that latency and CPU  
usage are 2 separate issues.  From what Louis said, I'm still not sure  
what problem he is experiencing.  Is it an issue with achieving low  
latency or an issue of the CPU consumption maxing out when playing  
certain MIDI files or many notes.

Even in the case where the sound card doesn't support 22050, it could  
actually reduce CPU, if the conversion by the ALSA plughw layer to  
44100 is less than required by the extra FluidSynth calculations for  
twice the number of samples per second.  I've never tested that  
myself, so its just a theory..  I wouldn't be surprised though if that  
is true.

At any rate.  It seems like the comments added by Louis are more  
useful for the case of reducing CPU usage, rather than reducing  
latency, which perhaps warrants a separate wiki page altogether.

The comment about 'Unfortunately specifying the hardware layer may  
bypass all of the desktop volume controls.' on the wiki, likely has to  
do with bypassing PulseAudio.  So that really belongs in a PulseAudio  
tips section.  Since if you are using ALSA mixer based audio controls,  
rather than PulseAudio mixer controls, that statement wont be true.

It is a mess indeed :(  O how I wish PulseAudio could achieve low  
latency.  It seems like a potentially nice audio system.  Sad to say,  
but it seems like if a user wants user friendly low latency audio,  
CoreAudio on OS X is where it is at currently.  I'm keeping my fingers  
crossed, that Linux and audio for the desktop AND the musician will be  
sorted out soon.

Cheers.

Josh