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