Repository navigation
[BUG][alsabat] glitches happened on MTL-HDA when testing headset recording #7298
Description
Describe the bug
I'm enabling alsabat test for headset recording and found some glitches on MTL-HDA. The reproduction rate is about 50% with all three test frequencies(599,821 and 997).
To Reproduce
~/sof-test/test-case/check-alsabat.sh -c hw:sofhdadsp,0 -p hw:CODEC,0 -C 2 -F 599
Need PR thesofproject/sof-test#1012
Reproduction Rate
50%
Environment
- Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
- Kernel: tip sof-dev
- SOF: tip main
- Name of the topology file
- Topology: sof-ace-tplg/sof-hda-generic-4ch.tplg
- Name of the platform(s) on which the bug is observed.
- Platform: MTLP_RVP_HDA
Activity
lgirdwood commentedon Mar 17, 2023
@keqiaozhang periodic issue with stream or just happens once in stream ? (if once when ?)
keqiaozhang commentedon Mar 20, 2023
From my observation, this is not a periodic issue, it only occurs at the beginning.
lgirdwood commentedon Mar 21, 2023
@keqiaozhang Is the timing of the glitch from beginning always consistent ? @btian1 is copier clearing buffer at start ?
keqiaozhang commentedon Mar 22, 2023
Yes, it's consistent and occurs within the first 1-2 milliseconds.
juimonen commentedon Mar 28, 2023
@keqiaozhang could you attach the mtrace also?
lgirdwood commentedon Mar 29, 2023
@singalsu fyi - your glitch dtetector should be able to emit output if glitch is in initial periods (i.e. trigger start/release) errors.
singalsu commentedon Mar 29, 2023
Currently it starts detect after stable signal level (waiting for ramp to complete) and analyze the FFTs after that. I would need to add a time domain glitch detector for the beginning part during ramp. The time domain is not as sensitive as FFT but it should work for glitches like this. I will try in next version for thesofproject/sof-test#1016
lgirdwood commentedon Mar 29, 2023
Thanks - this will save some triage time as these are two quite different bugs with different solutions when they occur.
wszypelt commentedon Mar 31, 2023
@keqiaozhang can you share the logs with payloads IPC logs.
3 remaining items
fredoh9 commentedon Apr 13, 2023
For today's daily test(planresultdetail/23512), sh-mtlp-rvp-hda-02 was used.
fredoh9 commentedon Apr 14, 2023
daily test(planresultdetail/23549), jf-mtlp-rvp-hda-2 was used,
all 3 alsabat capture was passed
First of all, it might be possibly device specific now.
2nd, do we have any fix for this merged already?
fredoh9 commentedon Apr 14, 2023
today's daily test failed on sh-mtlp-rvp-hda-03.
tested on sh-mtlp-rvp-hda-03 with same alsa settings with jf-mtlp-rvp-hda-2
check-alsabat-headset-capture-599.sh failed 3 out of 5. not 100% failure. At least it's not alsa settings issue.
bat_failed_sh-hda03.wav.gz
fredoh9 commentedon Apr 17, 2023
For today's daily test(planresultdetail/23660), device is sh-mtlp-rvp-hda-04, 599Hz pass, 821/998Hz failed
fredoh9 commentedon Apr 18, 2023
Yesterday @keqiaozhang checked on the device,
fredoh9 commentedon Apr 20, 2023
Removed P1 as some of devices have not reported the issue recently. The other devices (multiple) have ~20% failure rate though.
fredoh9 commentedon Apr 21, 2023
After compiling test results of +1 week, we have 5 devices for this model.
These two devices are solid pass for all,
Below 3 has ~20% failure, I don't see any failure pattern,
keqiaozhang commentedon Apr 24, 2023
Thanks Fred for debugging, I will try to figure it out.
lgirdwood commentedon Apr 25, 2023
@keqiaozhang @fredoh9 I wonder if it's the capture HW that has the glitch ? i.e. as the 2 DUTs that pass are a similar config to the DUTs that fail. Have you tried swapping capture/testing HW between DUTs ?
keqiaozhang commentedon May 15, 2023
Confirmed that this is a Hardware specific issue and only happens on SH DUTs. I'm debugging it.
keqiaozhang commentedon May 16, 2023
Issue fixed after connecting the stereo USB sound card to other USB port on MB. It seems that using USB HUB to power up the stereo sound card is not very stable.