[BUG] Glitches on asrc capture stress test.

[jdrzaszcz]

Describe the bug
When running simultaneous capture and playback on external loopback (same SSP) with ASRC component on capture pipeline, with playback iteration >= 75, there are small gliches on capturead wave. Therefore, the THD value in the wave verification is worse than expected.

Example captered stream

Spectogram:

Wave:

Topology

                +------------------+
    +------+    | +---+  +-------+ |
    | Host |----->|Buf|->|SSP Dai|------------------+
    +------+    | +---+  +-------+ |                |
                +------------------+                |
                                                    |
                +---------------------------------+ |
    +------+    | +---+  +----+  +---+  +-------+ | |
    | Host |<-----|Buf|<-|Asrc|<-|Buf|<-|SSP Dai|<--+
    +------+    | +---+  +----+  +---+  +-------+ |
                +---------------------------------+

To Reproduce
Ru slim driver python tests from file:
test_01_asrc_simple_capture.py
e.g.
TestAsrcCapture16000Hz16b16b2ch
TestAsrcCapture48000Hz32b32b2ch
TestAsrcCapture48000Hz16b16b2ch

Reproduction Rate
30 %

Expected behavior
Captured wave shouldn't have glitches.

Environment
I check it on: WHL RVP and TGL RVP,
but as I know from CI tests, it also happens on APL and ICL

Commit: 90ddae9 on SOF master branch

Logs for WHL RVP
dma_trace_1.log

19_01_TestAsrcCapture16000Hz16b16b2ch.zip

[singalsu]

Interesting, thanks for reporting @jdrzaszcz ! When doing 75+ tests, how long were each play/capture tests?

[jdrzaszcz]

@singalsu On each iteration we play 3 seconds stream.

[singalsu]

I'm now doing runs of 100x SPDIF ASRC capture test that includes THD+N measurement. I'm seeing variation of about 1 dB but so far no discontinuities. I'll continue tomorrow with more tests.

[singalsu]

I caught the first discontinuity, in my test the 3s clip THD+N dropped to -56 dB from usual -78 dB. The waveform looks like this, different looking than what you got. But it's definitely an error if it's not originated from SPDIF transmitter source.

[singalsu]

I've now run more than 1k of repeats and above has happened only once. Since it looks different than reported and with some kind of impulse train convolved I suspect it was a glitch from SPDIF source (macbook).

I will switch to diagnostic driver test where this reported issue happens. There was earlier also an issue that never happened with Linux driver.

[singalsu]

With a lot of help from @jdrzaszcz I have now replicated the issue with my setup and I have an initial fix done & under test. The pull mode filter core has an overrun condition protection that can happen but the SOF buffer update is not aware of the exception and thinks requested amount was processed.

[singalsu]

Update - with my test setup I seem to be able to fix the capture glitch issue but there's also for playback a stress test glitch seen for 8 kHz sample rate. It happens only with skew tracking enabled and I can made it disappear almost totally by making the loop filter unpractically slow. The jump in consumed samples originates from HW timestamping register. The samples count delta jumps while time delta remains stable.

So, I have not been able to properly fix it yet. I'll update now the PR with the work for capture, maybe it could be merged before my vacation. If yes, I could create a new issue for playback. As waveform it looks different and more severe with a rather big discontinuity.

[singalsu]

There was a regression in PR #3090. While addressing the consume/produce deviation from skew there was a mistake in capture pull mode copy limit for source buffer side. It caused the copy() to process less samples than required. The new PR is #3275.

[slawblauciak]

@jdrzaszcz the aforementioned PR has been already merged, can you retest and confirm if it's effective?