[alsa-devel] snd_pcm_avail_update() needed before snd_pcm_delay() with hda-intel

[Cristian Morales Vega]

2009/1/23 Cristian Morales Vega <cmorve69 at yahoo.es>:
> 2008/6/17 Christian Morales Vega <cmorve69 at yahoo.es>:
>> 2008/6/17 Takashi Iwai <tiwai at suse.de>:
>>> At Thu, 12 Jun 2008 20:32:51 +0200,
>>> Christian Morales Vega wrote:
>>>>
>>>> 2008/6/12 Takashi Iwai <tiwai at suse.de>:
>>>> > It's unlikely a driver issue but an incompatibility of dmix, I guess.
>>>> > But still I don't figure out why this happens.  The hwsync is done at
>>>> > each snd_pcm_dmix_delay() call (as long as slowptr is set, and it's so
>>>> > as default).  So, there shouldn't be any difference...
>>>> >
>>>> > What happens if you use "hw" or "plughw"?
>>>> With both plughw and hw works fine.
>>>>
>>>> If helps, I have simplified the problematic bsnes code into this:
>>>
>>> The program looks running fine on my machine with another HD-audio
>>> codec.  What is expected in the output and how wrong on yours?
>>
>> I knew I should not put it under the code :-p
>> "The listened effect is that when fails you listen the noise for just
>> buffer_time, and when works the noise never ends."
>>
>> So the output with the SB Live! is:
>> State: 2
>> Delay: 0
>> Passed
>> State: 2
>> Delay: 882
>> Passed
>> State: 2
>> Delay: 1764
>> Passed
>> State: 2
>> Delay: 2646
>> Passed
>> State: 2
>> Delay: 3528
>> Passed
>> State: 3
>> Delay: 4410
>> Delay/Goal: 4410/3528
>> State: 3
>> Delay: 4410
>> Delay/Goal: 4410/3528
>> State: 3
>> Delay: 4410
>> Delay/Goal: 4410/3528
>> State: 3
>> Delay: 4410
>> Delay/Goal: 4410/3528
>> State: 3
>> Delay: 4409
>> Delay/Goal: 4409/3528
>>
>> and so until delay reaches 3528, when a new snd_pcm_writei() is done.
>>
>> With the AD1988 the buffer is fulled one time. After that never again
>> reaches snd_pcm_writei(). The output is:
>> State: 2
>> Delay: 0
>> Passed
>> State: 2
>> Delay: 940
>> Passed
>> State: 2
>> Delay: 1880
>> Passed
>> State: 2
>> Delay: 2820
>> Passed
>> State: 2
>> Delay: 3760
>> Passed
>> State: 3
>> Delay: 4700
>> Delay/Goal: 4700/3764
>> State: 3
>> Delay: 4700
>> Delay/Goal: 4700/3764
>> State: 3
>> Delay: 4700
>> Delay/Goal: 4700/3764
>>
>> and so. Delay never decreases. But after some time you see.
>> State: 4
>> Delay: 4700
>> Delay/Goal: 4700/3764
>>
>> There has been an underrun even if appl_ptr is 4700 frames ahead of hw_ptr???
>> If you uncomment snd_pcm_avail_update() delay decreases and everything is ok.
>>
>
> I still have the same problem with alsa-1.0.19.git20090122-1.1 and
> alsa-driver-kmp-default-1.0.19.20090123_2.6.27.7_9.1-3.1 on openSUSE
> 11.1. Exactly same behavior: works with emu10k1, works with plughw...
> only doesn't works when using AD1988 and "default:1" device.
>
> Also reading Lennart Poettering discussion about snd_pcm_avail_update,
> snd_pcm_delay, etc I see bsnes is wrongly using snd_pcm_delay(). But I
> don't understand the snd_pcm_avail() vs snd_pcm_avail_update(). If
> snd_pcm_avail_update() doesn't calls hwsync the info it will return
> will be outdated/unuseful, will not? And how it is a call to
> snd_pcm_avail_update() fixes the problem I'm having here with
> snd_pcm_delay()? My problem isn't precisely the lack of a hwsync in
> snd_pcm_delay()?
> In snd_pcm_avail_update() doc: "The position is not synced with
> hardware (driver) position in the sound ring buffer in this function."
> isn't a contradiction with "Also this function might be called after
> snd_pcm_delay() or snd_pcm_hwsync() functions to move private ring
> buffer pointers in alsa-lib (the internal plugin chain)."? Probably
> I'm missunderstanding something. If snd_pcm_avail_update() isn't
> updating the same thing that snd_pcm_hwsync(), what it is updating?
>

Forget the last part. I suppose I just need to use snd_pcm_avail()
instead of snd_pcm_avail_update() if using mmap, true?

Only the "snd_pcm_delay() return value isn't updated" part is important.