intermittently incorrect channel order

[paulcox]

I apologize in advance for not being able to specify the exact conditions that result in this error, but I am at times seeing the channel order as 3,4,1,2 instead of the normal 1,2,3,4. It does not happen very often but causes very bad results for this application. A reboot nearly always fixes the problem. I wish I could say if this occurred only at boot or only after some time running, but for now I don't have that visibility. Could this be something going wrong at initialization or is it likely coming from a bug in the interrupts/dma operation? How can I isolate the issue or determine if it's in the processor DAI side or the ac108 side or Alsa? Any assistance to get to a root cause or workaround appreciated. Setup: Raspberry Pi CM3 with stock raspbian distro and ac108 with stock seeed/ac108 driver and alsa configuration including latest Dec commits. I've noticed to similar-ish bugs reported for both the DAI and ac108 sources so am hoping this is a known issue that I've just not been able to track down the bug-fix for. Thanks.

[turmary]

Hi paulcox,
We can't recurrent your problem on Raspbian Linux version 4.14.98-v7+(1.20190215-1).
So could you tell me more about your environment especially the software environment?

Using a high speed SDCard(Class 10 or higher) is helpful to prevent the problem.
Cause the overrun condition may be the problem root source.

[paulcox]

It is running Raspbian 9, with kernel 4.14.79-v7+. As for the seeed driver, we're using the version committed on github on january 26th (the commit hash is 6c6b9ab). I am using a Raspberry Pi Compute Module 3 and there is no SD Card in use, just the emmc flash on the module. Why might the SD Card be responsible? What's the theory? Something with interrupts getting mixed up or something? What is the overrun condition that you are referring to? Thanks.

[turmary]

Duplicate of #118

Overrun condition: #118
Your application is too slow to read ALSA audio buffer, the buffer will full.