On Sun, 10 Jan 2021 18:22:50 +0100 Takashi Iwai <tiwai@xxxxxxx> wrote: > On Sun, 10 Jan 2021 18:03:32 +0100, > Lauri Kasanen wrote: > > On Sun, 10 Jan 2021 11:24:22 +0100 > > Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > > > 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. > > > > > > Try to set the periods_min=2 and the integer periods hw constraint at > > > first, and change the pointer callback to return nextpos. Also, at > > > the push function, set runtime->delay = period_size as well. > > > > When I do all this, it still causes the chipmunk speed. Several seconds > > of audio gets played in 0.3s or so. Sorry if this is taking too much of > > your time, I'm a bit lost here at what the alsa core is expecting. > > > > Printks show the following repeats: > > start, period size 1024 > > push, bool irq=0 > > irq fired > > push, bool irq=1 > > pointer at 8192 > > stop > > Hm, is the above about the result with the pointer callback returning > pos, not nextpos? If so, It was returning nextpos, but the pointer printk was in bytes. 8192 bytes = 2048 frames. > > start, period size 1024 > > push, bool irq=0 > > At this moment, nextpos is 1024, and it should take some time until > > > irq fired > > ... this IRQ is triggered; it must be the period time. > Was the reported timing as expected? It's roughly correct, but timing is not very precise, as printk itself has heavy overhead for the 93 MHz cpu. - Lauri