[uae] Re: Bloody ALSA (was Re: Re: Source code snapshot)
- From: Jonathan Heaney <jonathan.heaney@xxxxxxxxxxxxxx>
- To: uae@xxxxxxxxxxxxx
- Date: Sat, 25 Mar 2006 23:20:50 +0000
Hi Richard
Richard Drummond wrote:
> 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
>
>
>
Thanks for looking into this for us. I'll maybe try and check it out to
confirm over the next week or so, as the nvidia binary driver I use
doesn't work with 2.6.16 (well, it didn't with the release candidate
ones I tried). Might be time to give alsa another spin.
Unfortunately on Gentoo here it involves a serious amount of arseing
about to make the transition.
Cheers,
Jonathan
Other related posts:
