[uae] Re: Bloody ALSA (was Re: Re: Source code snapshot)
- From: Richard Drummond <evilrich@xxxxxxxxxxxxxx>
- To: uae@xxxxxxxxxxxxx
- Date: Sat, 25 Mar 2006 01:34:39 -0500
On Saturday 25 March 2006 00:10, Richard Drummond wrote:
> Done some digging, reading and experimenting, and the problem seems to be
> ALSA's dmix plugin. If you specify the "default" ALSA device with recent
> ALSA versions, you automatically get dmix thrown on top and this adds its
> own substantial minimum latency. I don't know if there's a way to reduce
> that. The ALSA documentation isn't what you might call light reading.
You can edit your /usr/share/alsa/pcm/dmix.conf file and reduce the number of
periods in a buffer (dmix uses a fixed number of periods in a buffer, which
fixes the buffer size and so the latency). It defaults to 16 here. Knocking
this down to 4, for example, reduces the latency tolerably for me.
It looks like this problem will be fixed in libasound 1.0.11. From the
Changelog for 1.0.11rc4:
- Summary: dmix - Allow more flexible buffer sizes
With the patch, dmix allows apps to use more flexible buffer sizes.
The max buffer size is unlimited, and the minimal buffer size is
(period size * 2). The buffer size is aligned to period size.
The period size is still bound to the period size of slave PCM.
To back to the old behavior (the fixed buffer size), you can set
defaults.pcm.dmix_variable_buffer false
in your configuration.
Hope all this helps. ;-)
Cheersm
Rich
Other related posts:
