Repository navigation
[BUG][alsabat] glitches happened on MTL-HDA when testing headset recording #7298
Description
Activity
@keqiaozhang periodic issue with stream or just happens once in stream ? (if once when ?)
@keqiaozhang periodic issue with stream or just happens once in stream ? (if once when ?)
From my observation, this is not a periodic issue, it only occurs at the beginning.
@keqiaozhang periodic issue with stream or just happens once in stream ? (if once when ?)
From my observation, this is not a periodic issue, it only occurs at the beginning.
@keqiaozhang Is the timing of the glitch from beginning always consistent ? @btian1 is copier clearing buffer at start ?
Is the timing of the glitch from beginning always consistent ?
Yes, it's consistent and occurs within the first 1-2 milliseconds.
@keqiaozhang could you attach the mtrace also?
@singalsu fyi - your glitch dtetector should be able to emit output if glitch is in initial periods (i.e. trigger start/release) errors.
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
Reacted by Liam Girdwood@singalsu fyi - your glitch dtetector should be able to emit output if glitch is in initial periods (i.e. trigger start/release) errors.
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
Thanks - this will save some triage time as these are two quite different bugs with different solutions when they occur.
Reacted by Seppo Ingalsuo@keqiaozhang can you share the logs with payloads IPC logs.
3 remaining items
For today's daily test(planresultdetail/23512), sh-mtlp-rvp-hda-02 was used.
- check-alsabat-headset-capture-599.sh : failed
- check-alsabat-headset-capture-821.sh : pass
- check-alsabat-headset-capture-997.sh : pass
daily test(planresultdetail/23549), jf-mtlp-rvp-hda-2 was used,
all 3 alsabat capture was passed- check-alsabat-headset-capture-599.sh : pass
- check-alsabat-headset-capture-821.sh : pass
- check-alsabat-headset-capture-997.sh : pass
First of all, it might be possibly device specific now.
2nd, do we have any fix for this merged already?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.For today's daily test(planresultdetail/23660), device is sh-mtlp-rvp-hda-04, 599Hz pass, 821/998Hz failed
Yesterday @keqiaozhang checked on the device,
It’s not a device configuration issue, there’re some distortions in the waveform. This issue also can be reproduced on other devices, the reproduction rate is about ~20%.
Removed P1 as some of devices have not reported the issue recently. The other devices (multiple) have ~20% failure rate though.
After compiling test results of +1 week, we have 5 devices for this model.
These two devices are solid pass for all,
- jf-mtlp-rvp-hda-2.jf.intel.com
- jf-mtlp-rvp-hda-3.jf.intel.com
Below 3 has ~20% failure, I don't see any failure pattern,
- sh-mtlp-rvp-hda-04.sh.intel.com
- sh-mtlp-rvp-hda-02.sh.intel.com
- sh-mtlp-rvp-hda-03.sh.intel.com
After compiling test results of +1 week, we have 5 devices for this model.
Thanks Fred for debugging, I will try to figure it out.
@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 ?
Confirmed that this is a Hardware specific issue and only happens on SH DUTs. I'm debugging it.
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.
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