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

Hermann Lauer Hermann.Lauer at iwr.uni-heidelberg.de
Fri Jan 25 01:25:14 CET 2008


On Thu, Jan 24, 2008 at 04:40:18PM +0100, Takashi Iwai wrote:
> 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?

I don't know and the current implementation contains only a "don't ask why - AB"
comment.

To reiterate: My proposed patch is about minimising the chance that a
wrong hw pointer value is given back due to garbage read from the chip. If
you are interested, I can send you debugging output which shows
that both DMAADDR and DMACOUNT are read out as bogus values
from time to time - one or the another, or both. I tried some
status flags on the chip, but alway found cases where it's
not clear if and which one of the two is correct.

So reading both of them and comparing them seems to be the
best way for me to detect that there has been a readout error.
Which one to give back is without having more information
about the chip internals in my opinion only a matter of taste.
The proposed patch allows a jitter of one byte there, but that
could be set to zero at the cost of a slightly increased
failure rate.

> > > 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.

Fortunately I have not seen any signs of read errors during the interrupt
processing. Probably this would change if the interrupt processing latency
is high.

> 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.

Just to make that clear to me: If the irq handler calls
snd_pcm_period_elapsed() in your example, the alsa middle layer will treat
the first 256 byte as written completely by the chip even
if the pointer callback will say there is still one frame not stored
for that period.
(I see the name of the function answering my qestion, but are
curious how the middle layer implementation behaves in this situation)

That can play a role with the handling of the off-by-one bug of the chip.

Hermann 


-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: Hermann.Lauer at iwr.uni-heidelberg.de


More information about the Alsa-devel mailing list