> > > > > anyway, above patch might have fixed the issue and I was able to do some > > > measurements on a beagleboard (ARMv7, OMAP3, TPS65950 PMIC audio), > > > Linux kernel 3.7 and PA shortly before the srbchannel patches... > > > > Even the driver use SNDRV_PCM_INFO_NO_PERIOD_WAKEUP which is necessary but > > no sufficient > > > > For timer schedulling, the driver need to report dma residue > > and it look like some omap cannot report DMA residue granularity > > > > Can your hardware report dma residue granularity? > > > > <a href="https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/omap/omap-pcm.c">https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/omap/omap-pcm.c</a> > > > > static snd_pcm_uframes_t omap_pcm_pointer(struct snd_pcm_substream > > *substream) > > { > > snd_pcm_uframes_t offset; > > > > if (pcm_omap1510()) > > this is true for ancient OMAP1 only, OMAP3 uses snd_dmaengine_pcm_pointer() @DMA_RESIDUE_GRANULARITY_BURST: Residue is updated after each transferred burst. This is typically only supported if the hardware has a progress register of some sort (E.g. a register with the current read/write address or a register with the amount of bursts/beats/bytes that have been transferred or still need to be transferred). What is the dma brust size in this platform? Do this mean that the period size of your omap3 is multiple of dma brust size? Do this imply those starttheshold, hwbuf_unused,... need to be multiple of dma brust size? Do the dynamic latency range are just only finite points instead of continuous?