[BUG] JSL_RVP_NOCODEC check alsabat failed

[XiaoyunWu6666]

Describe the bug
happened since inner daily test 4887 , while 4882 is still good
when check-alsabat-playback ,get warning and the case failed

2021-06-30 02:52:56 UTC [COMMAND] alsabat -Phw:sofnocodec,0 --standalone -n 240000 -r 48000 -c 2 -F 997
alsa-utils version 1.2.2

Entering playback thread (ALSA).
Get period size: 2048  buffer size: 16384
Playing generated audio sine wave
2021-06-30 02:52:57 UTC [COMMAND] alsabat -Chw:sofnocodec,0 -c 2 -r 48000 -F 997
alsa-utils version 1.2.2

Entering capture thread (ALSA).
Get period size: 2048  buffer size: 16384
Recording ...
Capture completed.

BAT analysis: signal has 65536 frames at 48000 Hz, 2 channels, 2 bytes per sample.

Channel 1 - Checking for target frequency 997.00 Hz
Amplitude: 3228.7; Percentage: [9]
Detected peak at 0.73 Hz of 20.48 dB
 Total 28.3 dB from 0.73 to 16.11 Hz
 WARNING: Found low peak 0.73 Hz, very close to DC
Detected peak at 133.30 Hz of 16.15 dB
 Total 28.9 dB from 131.84 to 134.03 Hz
 FAIL: Peak freq too low 133.30 Hz
Detected peak at 276.86 Hz of 12.61 dB
 Total 29.0 dB from 276.86 to 276.86 Hz
 FAIL: Peak freq too low 276.86 Hz
Detected peak at 298.83 Hz of 10.16 dB
 Total 29.0 dB from 298.83 to 298.83 Hz
 FAIL: Peak freq too low 298.83 Hz
Detected peak at 399.17 Hz of 10.70 dB
 Total 29.1 dB from 399.17 to 399.17 Hz
 FAIL: Peak freq too low 399.17 Hz
Detected peak at 421.14 Hz of 12.06 dB
 Total 29.2 dB from 421.14 to 421.14 Hz
 FAIL: Peak freq too low 421.14 Hz
Detected peak at 443.12 Hz of 11.18 dB
 Total 29.2 dB from 443.12 to 443.12 Hz
 FAIL: Peak freq too low 443.12 Hz
Detected peak at 465.09 Hz of 11.16 dB
 Total 29.3 dB from 465.09 to 465.09 Hz
 FAIL: Peak freq too low 465.09 Hz
Detected peak at 542.72 Hz of 10.71 dB
 Total 29.4 dB from 542.72 to 542.72 Hz
 FAIL: Peak freq too low 542.72 Hz
Detected peak at 564.70 Hz of 12.48 dB
 Total 29.5 dB from 564.70 to 565.43 Hz
 FAIL: Peak freq too low 564.70 Hz
Detected at least 10 signal(s) in total

Return value is -1003

This is a regression , I use the sof recipe of inner daily test 4882 and it got a PASS back

To Reproduce
TPLG=sof-jsl-nocodec.tplg ~/sof-test/test-case/check-alsabat.sh -p hw:sofnocodec,0 -c hw:sofnocodec,0 -C 2
Reproduction Rate
100%

Environment
Kernel Branch: topic/sof-dev
Kernel Commit: 5b851f48
SOF Branch: main
SOF Commit: 2d70f10
Topology: sof-jsl-nocodec.tplg
Platform: jsl_rvp_nocodec

[plbossart]

@XiaoyunWu6666 please double-check that all mixer values are set to 0dB and all switches are on. I tested on Up2-nocodec and alsabat will only work if the mixer settings are correct. We did change the topology so the mixer values are likely incorrect.

[XiaoyunWu6666]

@XiaoyunWu6666 please double-check that all mixer values are set to 0dB and all switches are on. I tested on Up2-nocodec and alsabat will only work if the mixer settings are correct. We did change the topology so the mixer values are likely incorrect.

Yes alsabat only works well if the mixer settings are correct . If using the recipe on daily 4482 I can find some setting that fixs this case .However with 4887 , modifying the alsamixer seeting doesn't help to make things better.
If I set all the volume maximum , i got an

Channel 1 - Checking for target frequency 997.00 Hz
Amplitude: 3228.7; Percentage: [9]

If I set all mixer values 0db
then I got

Channel 1 - Checking for target frequency 997.00 Hz
Amplitude: 3228.7; Percentage: [0]

Is there any suspicious commit? Or should I do a bisect?

[XiaoyunWu6666]

replacing only the tplg file works.

[XiaoyunWu6666]

➜ sof git:(fdd8ec0) ✗ git bisect good fdd8ec0
b5b0b2c is the first bad commit
commit b5b0b2c
Author: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Date: Fri Jun 18 14:44:53 2021 -0500

topology: use same file for all cavs 1.8+ nocodec topologies

The beginning of the end of insanity?

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

tools/topology/topology1/CMakeLists.txt | 14 +-
tools/topology/topology1/sof-cavs-nocodec.m4 | 289 +++++++++++++++++++++++++++
tools/topology/topology1/sof-cnl-nocodec.m4 | 289 ---------------------------
tools/topology/topology1/sof-icl-nocodec.m4 | 176 ----------------
tools/topology/topology1/sof-tgl-nocodec.m4 | 186 -----------------
5 files changed, 296 insertions(+), 658 deletions(-)
create mode 100644 tools/topology/topology1/sof-cavs-nocodec.m4
delete mode 100644 tools/topology/topology1/sof-cnl-nocodec.m4
delete mode 100644 tools/topology/topology1/sof-icl-nocodec.m4
delete mode 100644 tools/topology/topology1/sof-tgl-nocodec.m4

[lgirdwood]

@XiaoyunWu6666 fwiw, I've also seen similar issues with background noise on the DUTs. Have you tried switching off the DUTs and test PC for an hour and retesting ?

[plbossart]

@lgirdwood in nocodec topologies, we use the loopback mode, there is not dependency on external components/noise.

@XiaoyunWu6666 the same topology works on APL and TGL, and locally on CNL. I don't think you root-caused the issue.

[plbossart]

I tried directly on the device and the recorded wave file is clearly complete garbage.

if this is a topology-only change it's probably in the SSP configuration then.

[plbossart]

The only thing I found in the topology was that going back to s24le seems to work...

@XiaoyunWu6666 can you retry with #4438. Make sure that you have all mixers to 0dB and switches on - asound.state attached below

jsl-nocodec-asound.state.txt

@lgirdwood @keyonjie any idea why the SSP seems to behave differently on ICL/JSL?