[alsa-devel] es1938 - patch trying to improve capture hw pointer reads

[Takashi Iwai]

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