[alsa-devel] bug in alsa-lib/snd_pcm_plugin_delay for capture?

[Jaroslav Kysela]

On Mon, 22 Nov 2010, pl bossart wrote:

>>>> Could you test patch bellow?
>>>>
>>>>
>>>> http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=ba9332e9192814a5431a3a2505d25d74a9232124
>>>
>>> Nah, no luck. PulseAudio still reports an error and if I add
>>> assert(*delayp >= *availp) the code bombs out.
>>> Here is one way to solve the problem. I don't claim it's the right
>>> one, but it's compatible with the way the availp value is computed,
>>> and it makes the error message go away in PulseAudio.
>>
>> The double avail_update() calling seems too expensive to me. Could you test
>> to use snd_pcm_mmap_capture_avail() instead snd_pcm_avail_update() calls (to
>> assign both slave_avail and plugin_avail local variables)?
>
> Nope, it still does not work if you use mmap_capture_avail. The root
> cause of the problem is the while loop in snd_pcm_plugin_avail_update
> (copied for reference below), it's called only in the capture case and
> the value returned by the xfer variable causes the delay to be
> eventually lower than the avail samples.

After rethinking, I believe that the right fix should be to add the 
'snd_pcm_mmap_capture_avail(pcm)' to the sd variable - delay(slave) - for 
the capture direction. You should not bother with avail_update or the 
slave avail values. The avail_update() capture loop just copied samples 
from the producer (slave) to the consumer (pcm). It means that the avail 
becomes lower for the producer (slave) and is increased for the consumer 
(pcm). The delay(slave) already contains the avail(slave) value.

So, the result should be 'delay(slave) + mmap_capture_avail(pcm)'.

 						Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.