[BUG][LNL] alsabat capture test sometimes fails when headset capture silent -> flaky MIC jack detect

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:

[ 4505.939899] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x5
[ 4505.939930] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, jack_type=0x3

Fail case dmesg:

[ 4550.810855] kernel: snd_soc_rt711_sdca:rt711_sdca_headset_detect: rt711-sdca sdw:0:0:025d:0711:01: rt711_sdca_headset_detect, detected_mode=0x3
[ 4550.810886] kernel: snd_soc_rt711_sdca:rt711_sdca_jack_detect_handler: rt711-sdca sdw:0:0:025d:0711:01: in rt711_sdca_jack_detect_handler, jack_type=0x1

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:

@fredoh9

@fredoh9 Can I ask you for logs with the IPC Payloads?

@fredoh9

@fredoh9 what about other codecs ? Does it pass or fail i.e. is it codec specific ?

Please check latest sof_fw.

@fredoh9

@fredoh9 When is the last sighting (w.r.t. @pjdobrowolski 's question above)?

@pjdobrowolski

@pjdobrowolski @fredoh9 This is still seen, latest in 29th Apr daily test plan. Also seen on PR CI runs on LNL today.

@fredoh9

@fredoh9 Can I ask you for logs with the IPC Payloads?

I will capture the log with IPC payloads.

@fredoh9 what about other codecs ? Does it pass or fail i.e. is it codec specific ?

We don't have the problem with HDA codec.

detected_mode=0x3 means the codec did not detect a capture mic so it's not really a surprise that the capture is silent...
We should log the 'Headset Mic Jack' control value in sof-tests, that would tell us if the test can work or not...

@wszypelt

@wszypelt please find attached dmesg with ipc payloads and mtrace. This is when test failed, output wave has just silence.

dmesg_ipc_payloads.txt
mtrace.txt

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

@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.

hexdump -C ~/Downloads/bat_wav_pass_and_fail\ \(1\)/bat.wav.fail 
00000000  52 49 46 46 44 62 05 00  57 41 56 45 66 6d 74 20  |RIFFDb..WAVEfmt |
00000010  10 00 00 00 01 00 02 00  80 bb 00 00 00 ee 02 00  |................|
00000020  04 00 10 00 64 61 74 61  20 62 05 00 00 00 00 00  |....data b......|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00056240  00 00 00 00 00 00 00 00  00 00 00 00              |............|
0005624c

@fredoh9

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 jf-lnlm-rvp-sdw-1 board itself (NOT the AIOC) and see what happens. It turned out to be a good idea.

Long story short:

SW_HEADPHONE_INSERT detection seems 100% reliable
SW_MICROPHONE_INSERT detection is flaky

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:

evtest

Event: time 1714768171.329763, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1714768171.329763, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 1
Event: time 1714768171.329763, -------------- SYN_REPORT ------------

with headphones:

Event: time 1714768266.928076, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1714768266.928076, -------------- SYN_REPORT ------------

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:

Event: time 1714768134.485890, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
Event: time 1714768134.485890, -------------- SYN_REPORT ------------
Event: time 1714768134.693872, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
Event: time 1714768134.693872, -------------- SYN_REPORT ------------
Event: time 1714768134.693941, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
Event: time 1714768134.693941, -------------- SYN_REPORT ------------
Event: time 1714768134.901633, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
Event: time 1714768134.901633, -------------- SYN_REPORT ------------
Event: time 1714768134.901692, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
Event: time 1714768134.901692, -------------- SYN_REPORT ------------
Event: time 1714768135.109444, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
Event: time 1714768135.109444, -------------- SYN_REPORT ------------
Event: time 1714768135.110116, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
Event: time 1714768135.110116, -------------- SYN_REPORT ------------
Event: time 1714768135.314664, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
Event: time 1714768135.314664, -------------- SYN_REPORT ------------

@marc-hb

@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 options snd_soc_sof_sdw quirk to see if any of the values work? As I know, MTL RVP on board rt711 JD source is JD2_100K, and AIOC4.1's JD source is JD2. But I don't know about LNL RVP on board rt711.
In theory, it should be realizable if you set options snd_soc_sof_sdw quirk=0x2 when you test with LNL RVP + AIOC.
And one of options snd_soc_sof_sdw quirk=0x1, 0x2, or 0x3 should work when you test with LNL RVP on board rt711.
Please test with a normal headset first. And switch to the splitter once the headset is detected realizably.

@bardliao

@bardliao @plbossart @marc-hb
I tried with 'options snd_soc_sof_sdw quirk=2', in fact tried 1,2,3 all. I don't see any difference.
This doesn't need thesofproject/linux#4969, but just in case I tried with/without thesofproject/linux#4969, no difference.

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

EDIT: https://sof-ci.01.org/softestpr/PR1193/build420/devicetest/index.html?model=LNLM_SDW_AIOC&testcase=check-alsabat-headset-capture-599

https://sof-ci.01.org/softestpr/PR1193/build426/devicetest/index.html?model=LNLM_SDW_AIOC&testcase=check-alsabat-headset-capture-599

@marc-hb

NOCODEC issues are tracked here @marc-hb #9123

This is a different setup since the loopback is at the SSP level, i.e. not dependent on any codec/jack

@fredoh9

@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?
FYI @abonislawski @dnikodem on the potential FW issue above. See e.g. bat.wav in https://sof-ci.01.org/linuxpr/PR4899/build2589/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-alsabat-headset-playback-821

@kv2019i

Agree with @kv2019i the two issues seem quite different and well partitioned between kernel/firmware.
I'll move #9123 to firmware.

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.

but it's still not predictable even with the basic 3-rings and 4-rings headphone and headset that I tried.

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:

[BUG] Gen4.1 AIOC rt711 : jack detection and alsa-bat capture fail linux#4681 (comment)

Navigation Menu

Repository navigation

[BUG][LNL] alsabat capture test sometimes fails when headset capture silent -> flaky MIC jack detect #9018

14 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG][LNL] alsabat capture test sometimes fails when headset capture silent -> flaky MIC jack detect #9018

Description

Activity

wszypelt commented on Apr 22, 2024

lgirdwood commented on Apr 22, 2024

pjdobrowolski commented on Apr 23, 2024

kv2019i commented on Apr 23, 2024

kv2019i commented on Apr 30, 2024

fredoh9 commented on Apr 30, 2024

plbossart commented on Apr 30, 2024

fredoh9 commented on Apr 30, 2024

marc-hb commented on May 1, 2024

lgirdwood commented on May 1, 2024

14 remaining items

plbossart commented on May 3, 2024

marc-hb commented on May 3, 2024

bardliao commented on May 6, 2024

fredoh9 commented on May 8, 2024

marc-hb commented on May 13, 2024

marc-hb commented on May 13, 2024

plbossart commented on May 13, 2024

kv2019i commented on May 14, 2024

plbossart commented on May 14, 2024

plbossart commented on May 14, 2024

marc-hb commented on May 17, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions