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

[Cristian Morales Vega]

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?