-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG][LNL] alsabat capture test sometimes fails when headset capture silent -> flaky MIC jack detect #9018
Comments
@fredoh9 Can I ask you for logs with the IPC Payloads? |
@fredoh9 what about other codecs ? Does it pass or fail i.e. is it codec specific ? |
Please check latest sof_fw. |
@fredoh9 When is the last sighting (w.r.t. @pjdobrowolski 's question above)? |
@pjdobrowolski @fredoh9 This is still seen, latest in 29th Apr daily test plan. Also seen on PR CI runs on LNL today. |
|
@wszypelt please find attached dmesg with ipc payloads and mtrace. This is when test failed, output wave has just silence. |
Another failure today (with logs and .wav file) in public https://sof-ci.01.org/sofpr/PR9013/build4396/devicetest/index.html Many more failures and logs in daily tests, see a long list in internal issue 561. This is failing on at least one device (out of 3) in more than 50% of test runs. Interestingly, when one device fails then it tends to fail ALL headset capture tests (or none) |
@fredoh9 @marc-hb what is the test capture device here - the fail capture WAV is all 0s. I would expect to see analog noise (i.e. LSBs toggling) if we capture silence rather than all 0s. i.e.
|
Based on discussions in the older, longer and internal issue 561, the main suspect is jack detection. Does this help? |
Yep, jack detect could power off the ADCs and give 0s. |
@fredoh9 Just to double-check, are we using the same add-in cards for MTL and LNL RVPs? I am not sure why jack detection seems to be flaky only on LNL, this is a codec functionality which doesn't really have any correlation with the SOC-side of things. |
@plbossart yes, we are using same AIOC4.1 for MTL/LNL Just remembered, AIOC4.1 is same but for LNL, we were running out of the cards, I found a box of un-used AIOC4.1 in the storage room, I shared that AIOCs. I can try to swap the codec board between MTL and LNL also. |
I think it's worth exploring if we are dealing with board-specific issues. If I am not mistaken we have zero issues with MTL+AIOC, so if we swap the boards and see a problem appearing no MTL then the board is the problem. Also are we using the same dongles or plugs for the analog loopback? |
same brand USB soundcard is used but other cables and Y splitter are varying, brand, length, quality etc. |
If these are "randomly" and relatively evenly distributed across MTL and LNL then we can ignore them because the reproduction rate is very high on LNL (~ 30%) and absolutely 0% on MTL |
I swapped the AIOC between jf-mtlp-rvp-sdw-7 and jf-lnlm-rvp-sdw-1
MTL shows very solid pass but LNL is not. The jack connected is in RVP not the codec board. Not sure if there is a difference in the schematic, should not be. |
@fredoh9 what do you mean by "The jack connected is in RVP not the codec board." Does this mean we have analog wires going from the connector on RVP all the way to the codec board? I've never seen this done, usually when there's an add-on board with a jack codec, it comes with its own connector. @bardliao what do you think? |
@fredoh9 Can you try with |
Apparently we are NOT using the RT711 on the AOIC board, but the one on the RVP motherboard @bardliao |
Because we thought the RVP/AIOC connection could be a problem, but later we realized that the AIOC is irrelevant. It's the RVP that's the problem apparently. We could double-check this by removing the AIOC completely and see if we still have alsa-bat/jack detection issues. |
I tried only onboard rt711 without AIOC connection at all. I had same problem. LNL with/without AIOC has consistent problem, which is good. |
Thanks @fredoh9 for this, now I think it makes sense. We can point to the LNL RVP as having jack detection issues. I guess we really need the selected_mode override that @shumingfan started in PR thesofproject/linux#4969 |
Because we're looking at jack detection issues, I had this outlandish validation idea of... walking to the lab and simply trying to manually plug and unplug various jacks into the Long story short:
SW_MICROPHONE_INSERT is even LESS reliable with the splitter we use (see picture in thesofproject/linux#4681) but it's still not predictable even with the basic 3-rings and 4-rings headphone and headset that I tried. In theory, with headset:
with headphones:
In practice I get one or the other RANDOMLY with everything I tried to plug in. Interestingly enough, in rare cases I also get a burst of these despite me not actually pressing any button:
|
@marc-hb @fredoh9 I thought the issue only happens with the splitter, but no issue with normal headset. Can you try with different values of |
@bardliao @plbossart @marc-hb |
Still failing even when forcing the jack detection, "signal too week" 3 times in a row: https://sof-ci.01.org/sofpr/PR9119/build4654/devicetest/index.html |
This comment was marked as off-topic.
This comment was marked as off-topic.
@fredoh9 @plbossart @marc-hb Agree there are two distinct issues here. Should we move this SDW one to kernel. Looking at the bat.wav captures of failing cases, this seems more like a codec issue. The nocodec issue (#9123) seems more like a potential FW issue as the start of capture is clean, but then we have errors in captured PCM samples. This doesn't look like a codec issue at all. Should we move 4964 to FW and this SDW issue to kernel? |
we already have a kernel issues for jack detection/AIOC, closing this one. Let's use thesofproject/linux#4681 which has historically been reported first. |
That was wrong sorry, I was using some bad headphones! I plugged and unplugged various (good!) jacks hundreds of times again and the microphone detection is reliable EXCEPT when connecting a LINE OUT to the microphone. More at: |
CLOSED as DUPLICATE of thesofproject/linux#4681
Describe the bug
LNL L0 RT711 headset capture sometimes silent and alsabat capture test fails.
Platform is LNLM_SDW_AIOC, but alsabat test on RT711 codec only.
alsabat playback test looks consistent but alsabat capture test has mixed passes and failures.
mtrace doesn't have much difference.
Good case dmesg:
Fail case dmesg:
To Reproduce
Frequency doesn't matter.
TPLG=/lib/firmware/intel/sof-ipc4-tplg/sof-lnl-rt711-l0-rt1316-l23-rt714-l1.tplg MODEL=LNLM_SDW_AIOC SOF_TEST_INTERVAL=5 ~/sof-test/test-case/check-alsabat.sh -c hw:sofsoundwire,1 -p hw:CODEC,0 -C 2 -F 997
Reproduction Rate
Very easy to reproduce, one fail the other pass or vice versa.
Expected behavior
Capture output should have sinewave always.
Screenshots or console output
captured wave files:
bat_wav_pass_and_fail.zip
dmesg snapshot:
lnl_dmesg_bad.txt
lnl_dmesg_good.txt
cc:
The text was updated successfully, but these errors were encountered: