At Fri, 25 Jan 2008 01:25:14 +0100, Hermann Lauer wrote: > > 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. Yeah, it would be helpful to understand the problem more correctly. > 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. BTW, don't get me wrong - I'm not against your proposal. The back-off is a safe option, as already mentioned. > > > > 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. Probably. In the other case, if some other device blocks the shared irq line, then the irq handle gets sloppy. In such a case, the sound driver gets an irq for the update of two periods instead of one. > > 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) Yes. The return value from the pointer callback is the most trusted information the PCM core receives. > That can play a role with the handling of the off-by-one bug of the chip. What is the problem exactly? Thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
