On Sat, 09 Jan 2021 21:54:12 +0100 Takashi Iwai <tiwai@xxxxxxx> wrote: > When the start starts, it copies the full period size data, and moves > nextpos to period size while keeping pos 0. And, at this moment, it's > even possible that no enough data has been filled for the period > size; this is practically a buffer underrun. > Usually PCM core can catch the buffer underrun by comparing the > current position reported by the pointer callback against the filled > size, but in this case, PCM core can't know of it because the driver > just tells the position 0. This is one problem. > > Then, at the first period IRQ, the next period is copied, then nextpos > becomes 2*period_size. At this moment, pos = nextpos, hence it jumps > from 0 to 2*periodsize out of sudden. It's quite confusing behavior > for applications. That's the second problem. > > I guess that both problems could be avoided if n64audio_pointer() > reports always nextpos instead of pos. At first there was no nextpos, and _pointer() always reported pos. This didn't work, the core played through the audio at chipmunk speed. So there must be more that I don't understand here. Let me describe the hw, perhaps a different approach would be better. - the DMA unit requires 8-byte alignment and 8-divisible size (two frames at the only supported format, s16be stereo) - the DMA unit has errata if (start + len) & 0x3fff == 0x2000, this must never happen - the audio IRQ is not a timer, it fires when the card's internal buffers are empty and need immediate refill - Lauri
