[BUG] glitch in test 02_02_TestPtpSimpleLoopbackMasterRecord16000Hz32b32b4ch

[wszypelt]

Describe the bug
Glitch was found in test 02_02_TestPtpSimpleLoopbackMasterRecord16000Hz32b32b4ch
Playback pipeline is connected to slave SSP, capture pipeline is connected to master SSP.

Topology

pipe_plb
+------------------------------+
|-------+   +------+   +-----+ |   +----+
|| Host +-->+Buffer+-->+ Dai +---->+SSP1|
|-------+   +------+   +-----+ |   +----+
+------------------------------+    |  |
                                    |  |
pipe_cap                            |  |
+------------------------------+    |  |
|-------+   +------+   +-----+ |   +----+
|| Host +<--+Buffer+<--+ Dai +---->+SSP0|
|-------+   +------+   +-----+ |   +----+
+------------------------------+

To Reproduce
Run test with Diagnostic driver 02_02_TestPtpSimpleLoopbackMasterRecord16000Hz32b32b4ch
With options --playback-iterations=75

Reproduction Rate
1/75

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • SOF BRANCH: main HASH: dc0ab8a
2. Name of the platform(s) on which the bug is observed.
   Platform: ICL RVP
3. Test environment:
   BRANCH: master HASH: 180819001ee5c678ee2b6a53b4931c605a14e89c

Screenshots or console output

02_02_~1.ZIP

[lgirdwood]

@wszypelt @zrombel Not sure if we can use the same buffer for both host and DAI DMA - please confirm if topology diagram is correct.

[zrombel]

As I mentioned in #4076:

This image can be a little bit confusing as "Host plb" and "Host cap" component are a part of pipelines (test documentation needs a fix). Regarding buffers: buffers shown on topology are buffers that are explicitly created by test logic by IPC "TplgBuffNew" but as far as I know one another buffer is being created implicitly by FW for data from host DMA - those buffers are not included in tests topology drawings. Please correct me if I'm wrong.

[wszypelt]

The same issue at the same reproduction appears in test
02_01_TestPtpSimpleLoopbackMasterPlayback16000Hz32b32b4ch

[lgirdwood]

@zrombel @kkarask @wszypelt @XiaoyunWu6666 @keqiaozhang @keyonjie @slawblauciak fwiw we are seeing a lot of glitches being reported recently in various loopback tests.
Can we do the following here

1. Align these under one issue and mark the others as duplicates, they all seem to show repeated or skipped samples which is usually indicative of races between DMA and DSP buffer IO.
2. Duplicate these failures using an existing upstream topology as its difficult to reproduce for developers who do not have access to HW with the slim test framework.

[lgirdwood]

Duplicate of simpler #4076

[kkarask]

Glitch was found also in test where playback pipeline is connected to master SSP, capture pipeline is connected to slave SSP (02_01_TestPtpSimpleLoopbackMasterPlayback48000Hz32b32b4ch).
Reproduction rate: 2/75.

[lgirdwood]

@kkarask we think we may be getting closer to why the python driver and the no_codec CI devices are showing some issues as more reproducible. Python driver and no codec mode are probably sending IPCs for some sequences faster that the kernel driver in codec mode (as codec mode means lots of slow & blocking I2C IO with codecs).

Can you rerun the test with #4471 locally merged and let us know if there are any changes to above result with Python driver.
@mwasko fyi.

[kkarask]

@lgirdwood I rerun tests on #4471 and tests passed, but problem can still exists because reproduction rate is not high. See also related issue: #4180

[lgirdwood]

@lgirdwood I rerun tests on #4471 and tests passed, but problem can still exists because reproduction rate is not high. See also related issue: #4180

Thanks @kkarask, do you mean that #4471 decreases the reproduction rate ? if so by how much ?