On Sun, Dec 23, 2018 at 11:16:31AM +0800, Chen-Yu Tsai wrote: > This sounds like the flush is happening after DMA transfers and/or I2S > operations have started, disrupting the order of the audio samples. I > think that might be the case since the regcache is synced sequentially, > and the FIFO control register is after the enable bits. That would imply > that the device is taken out of runtime suspend after the .start_capture > or .start_playback callbacks. Not sure if that's the case, but that would > mean the bus clocks are still off at this point, and bypassing the cache > and updating the bits is basically moot. I would expect that the device needs to be resumed from suspend before we start actually trying to transfer audio - there is stuff in the ASoC core which is supposed to have appropriate gets but it's possible something is going wrong there. > I think there's something else happening here, but we need to figure it > out instead of papering over it with something that "just works" but > we don't know why it works. I agree.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
