Switching between different input sources causes XRun problems

[gavin_lin]

We are now using the 4.14.98-2.3.0 version of the kernel,and the SOC is IMX8MN,and we are now sufferring an audio source switching XRun problems.
The following is a detailed description.

We are creating several soundcards through kernel level.
Card 0: SPDIF record (SPDIF1)
Card 1: SOUNDBOX playback (SAI5,IMX8MN master,SOUNDBOX slave)
Card 2: ES8388 record&playback (SAI3,IMX8MN master,ES8388 slave)
Card 3: ATS2819Z record (SAI7,IMX8MN slave,ATS2819Z master)
Card 4: UAC2ACOUSTICLIN record&palyback (UAC2.0)

Test 1:
Our application open all the soundcards,and define Card1(SOUNDBOX) as the Playback Card,Card0/2/3/4 as the Record Cards,switch the Record Cards randomly every second.
The test results showed that all the audio path combinations had XRun problems. And the worst result is that the Playback Card has no sound output at all.
The following is an analysis of this problem by Application Engineering.

---------------------------------------------
I am reaching out to report our findings from testing the audio interface switch functionality on the soundbar. We set up a number of stress tests which perform repetitive switches between pairs of ALSA devices, basically capture devices (inputs). We noticed these switches sometimes (i.e., after a nondeterministic number of repetitions) lead to states where no audio is played out anymore. Once this has happened, no audio is played out irrespective of the audio input, that is, subsequent switching of the input does not resolve the problem.

On closer inspection, it appears that the error is actually caused by the playback (=output) device, if the loudspeaker array output is used. After a faulty switch of the capture device, the playback device is blocking indefinitely. That is, ALSA API functions as snd_pcm_writei() or snd_pcm_wait() block indefinitely or return after the timeout period. At the same time, the playback device appears perfectly normal, that is:

1. Function calls do not return error values.
2. The state is reported as SND_PCM_STATE_RUNNING, which is correct.
3. We can perform any kind of operation, i.e., snd_pcm_drop(), snd_pcm_prepare(), snd_pcm_recover(), snd_pcm_start() ..., all with the expected behaviours and no error return values.

Nonentheless, the blocking behaviour of the playback device persists on repeated calls to snd_pcm_writei() or snd_pcm_wait().
---------------------------------------------

Test 2:
Our application open all the soundcards,and define Card2(ES8388) as the Playback Card,Card0/2/3/4 as the Record Cards,switch the Record Cards randomly every second.
1. Switching Card2 and Card3 every second,there is no XRun problem.
2. Switching Card2 and Card4 every second,there is no XRun problem.
3. Switching Card3 and Card4 every second,there is XRun problem.

I think the reason why there is no XRun problem is that we are using the same clocks to record and playback(SAI3).

How can we optimize this problem?

Thanks,
Gavin

[jamesbone]

Using the higher data lanes SAI1_TX_DATA4/5 may use other FIFO's than the ones used by SAI1_TX_DATA0/1/2/3,

Try to use Please add the following lines to the device tree of &sai1
fsl,sai-multi-lane;
fsl,dataline = <0 0xff 0xff 2 0xff 0x30>;