On Wed, 13 Jan 2021 12:57:16 +0100, Lauri Kasanen wrote: > > On Mon, 11 Jan 2021 16:25:08 +0100 > Takashi Iwai <tiwai@xxxxxxx> wrote: > > > On Mon, 11 Jan 2021 13:02:22 +0100, > > Lauri Kasanen wrote: > > > This order gives correct pointer advancing etc, but now it's hitting a > > > new problem: the pcm core is reusing the buffer from under the audio > > > card. It's writing new data to the area that is currently being read by > > > DMA. > > > > Could you elaborate? I still don't get what's going on there. > > I figured it out. Turns out the hw registers were double-buffered in a > way that requires two periods' worth of buffers. The IRQ fires when one > buffer is finished and another is queued, not when everything is > finished as I first thought. > > There doesn't seem to be a way to request the PCM core to keep two > periods' distance instead of one? I will deploy memcpy then. We may return to the first approach, i.e. just use nextpos. But then snd_pcm_period_elapsed() has to be called right after the trigger callback without the IRQ, because the trigger START already queued the full period and the position advances. So the first period-elapsed has to be called from a work or such offload instead of IRQ. In anyway, it's a bit tricky, yeah. Takashi
