At Fri, 6 Jun 2008 20:46:12 -0400, Lee Revell wrote:
On Fri, Jun 6, 2008 at 3:54 PM, Christian Morales Vega cmorve69@yahoo.es wrote:
snd_pcm_avail_update() documentation says: "Using of this function is useless for the standard read/write operations. Use it only for mmap access. See to snd_pcm_delay."
snd_pcm_delay() documentation says: "Note this function does not update the actual r/w pointer for applications. The function snd_pcm_avail_update() have to be called before any begin+commit operation."
My english is far from perfect, and so the problem can be that I missunderstood the docs but: 1- "Using of this function"? Should not be "Use of this function"?
I would just say "This function is useless for...".
Patch please ;)
2- Is snd_pcm_avail_update() really useless when not using mmap?
The pcm.c example referenced right below that comment would indicate otherwise:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g41ca534658...
I have a SB Live! where snd_pcm_delay() always returns the correct value, without any need for snd_pcm_avail_update(). But the same code in the same machine with an hda-intel AD1988 needs a call to snd_pcm_avail_update() before snd_pcm_delay() to give the correct result. Without it snd_pcm_delay() always returns the value that *was* correct in the last snd_pcm_writei() call.
So should the "application frame position" be always updated, or only in read/write operations? In the first case AD1988 fails, in the second case perhaps SB Live! is making too mucho work ;-)
Is this with the latest ALSA HG sources?
The SBLive driver is better working and more mature, so I'd presume it to be correct. Takashi-san?
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"?
Takashi