Quoting Pedro Lopez-Cabanillas <[email protected]>:
On Monday, May 25, 2009, [email protected] wrote:
Quoting Pedro Lopez-Cabanillas <[email protected]>:
> 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
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
