On 24/09/2019 22.40, Mark Brown wrote: > On Tue, Sep 24, 2019 at 02:41:46PM +0300, Peter Ujfalusi wrote: > >> It can only fixed by using different sequence within trigger for 'stop' and >> 'start': >> case SNDRV_PCM_TRIGGER_START: >> case SNDRV_PCM_TRIGGER_RESUME: >> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: >> Start DMA first followed by CPU DAI (currently used sequence) >> >> case SNDRV_PCM_TRIGGER_STOP: >> case SNDRV_PCM_TRIGGER_SUSPEND: >> case SNDRV_PCM_TRIGGER_PAUSE_PUSH: >> Stop CPU DAI first followed by DMA > > Yeah, this makes sense I think. > >> If I think about the issue, I'm not sure why it was not noticed before as the >> behavior makes sense: >> we stop the DMA first then we stop the CPU DAI. If between the DMA stop and DAI >> stop we would need a sample in the DAI (which is still running) then for sure we >> will underrun in the HW (or overrun in case of capture). > > There are a bunch of systems where the trigger only actually does > anything with one or the other of the IPs and the startup for the > other is handled by a hardware signal so the ordering doesn't > really matter for them. If they use generic dmaengine pcm then their DMA is going to be stopped/paused in trigger. Not sure how they can handle in DAI when the DMA is stopped. >> Not sure if anyone else have seen such underrun/overrun when stopping a stream, >> but the fact that I have seen it with both UDMA+PDMA and EDMA on different >> platforms makes me wonder if the issue can be seen on other platforms as well. > > I'd guess so, especially with smaller buffers. I have sent the non RFC patch with fix to the not initialized ret and updated commit message to document the trigger sequences for start and stop type of events. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
