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

[Takashi Iwai]

At Fri, 25 Jan 2008 17:07:27 +0100,
Hermann Lauer wrote:
> 
> On Fri, Jan 25, 2008 at 11:44:12AM +0100, Takashi Iwai wrote:
> > > > 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.
> > 
> > Yeah, it would be helpful to understand the problem more correctly.
> 
> Will put together some of the log files next week.
> Up to what size could/should  I cc to the list without upsetting people ?
> I guess compressing them will yield only a few KBytes.

Not sure about the size limit, but it'd be better to attach a
compressed file.  Or just cut out only the interesting part.

> > > That can play a role with the handling of the off-by-one bug of the chip.
> > 
> > What is the problem exactly?
> 
> If I interpreted my tests output correctly, the last byte of a period
> is written by the DMA engine after the interrupt occurs. So the
> hw pointer probably has to be decremented by one and is then
> pointing to the last frame (Or even that before: Has the hw pointer to point
> at the frame which is written at the moment or the one which is
> guaranteed to be written completely by the hardware ?)

This sounds a bit odd.  Isn't it rather the setup of the hardware
parameter wrong?  I mean, the count calculation in *_prepare() can be
the size - 1?  


Takashi