At Thu, 24 Jan 2008 16:21:02 +0100, Hermann Lauer wrote:
On Thu, Jan 24, 2008 at 12:47:46PM +0100, Takashi Iwai wrote: ...
Thanks for the patch. The change look OK to me. Another idea would be to use DMAADDR only when DMACOUNT goes mad.
The problem is to decide when you have read garbage from DMACOUNT. DMAADDR is better in the first place, because you know the range in 24 bit which is valid (DMACOUNT is 16bit only). But my patch tries to make the failure probability much more lower by reading and comparing both, so from which one you calculate the pointer at the end is only a cosmetic issue.
Then a question arises - why DMAADDR isn't used as the primary source at all? Is it less stable than DMACOUNT in some cases?
But the back-off to the last pointer is propbably a safer solution.
I'm glad to hear the alsa design allow's this trick - or is that even the recommeded way to deal with when the hardware pointer could be temporarily not determined ?
Well, not really. In theory, it works even if the driver doesn't provide the accurate position. But, the driver must provide the position in the current period, i.e. the accuracy (latency) must be smaller than the period size. Thus, it's more safer to keep tracking the current period index (e.g. incrementing at each period-update irq) and check whether the last ptr is over it.
For example, suppose the buffer = 256 x 4 periods. The last ptr is recorded at 256. Now, at the real position 512, an irq is issued. The irq handler calls snd_pcm_period_elapsed(), which calls the pointer callback in the PCM core. If the read error occurs at this moment, we can't back up to the last position 256. We are supposed to be at position 512 or more.
The patch is, however, unable to apply as is because of coding style problems. Try $LINUXKERNEL/scripts/checkpatch.pl, fix what are suggested there, and repost the patch together with your sign-off.
Will do that when I digged trough the details (have to learn about signing).
See $LINUX/Documentation/SubmittingPatches.
Takashi