[BUG] Gen4.1 AIOC rt711 : jack detection and alsa-bat capture fail

[keqiaozhang]

Describe the bug
On both MTL and LNL RVPs, we connected the Gen4.1 AIOC board to check Soundwire codec ALC711, but we found that the headset switch always off if no real headset(w/ mic) connected. In our test scenario, we connect the USB sound card to rt711 headset port and take the output of the USB sound card as the input to RT711 by using an audio splitter cable. In this way, the headset switch always off and nothing can be recorded.
I also tried 'options snd_soc_sof_sdw quirk=2', it can turn on the headset switch, but there is still an ~80% chance that no data will be recorded.

I hope there's a workaround to change the codec behavior.

To Reproduce
~/sof-test/test-case/check-alsabat.sh -c hw:sofhdadsp,0 -p hw:CODEC,0 -C 2 -F 997

Reproduction Rate
80%.

cc:

• DUPLICATE [BUG][LNL] alsabat capture test sometimes fails when headset capture silent -> flaky MIC jack detect sof#9018
• [MTL] SoundWire: unreliable headset detection on Dell SKU 0CC7 #4872
• ASoC: rt711-sdca: add GE selected mode control #4969
• Fixup! ASoC: rt711-sdca: add GE selected mode control #4996

[plbossart]

@shumingfan is there a way to use the line-in on RT711-SDCA? From the spec the user should be able to set the 'Selected Mode' for the GE entity, no?

[shumingfan]

@shumingfan is there a way to use the line-in on RT711-SDCA? From the spec the user should be able to set the 'Selected Mode' for the GE entity, no?

@plbossart You mentioned that would be the UAJ case. That will be manual mode to configure the different endpoints the user selected.
However, the rt711-sdca codec driver configures the HW CBJ detection mode. The detected_mode reports HP or Headset.

I tested the rt711 on Gen4.1 AIOC on my side and the jack detection source will be RT711_JD2.
It doesn't have the alert interrupt when the codec driver sets other jack detection sources like RT711_JD1 or RT711_JD2_100K.
@keqiaozhang We discussed this issue, you said the jack detection works even after setting RT711_JD2_100K.
I'm not sure what the problem is. Do you have another AIOC board to test again?

[keqiaozhang]

@keqiaozhang We discussed this issue, you said the jack detection works even after setting RT711_JD2_100K. I'm not sure what the problem is. Do you have another AIOC board to test again?

Yesterday I tried RT711_JD2_100K, it only works in specific situations:

1. turn headset MIC switch on
2. play audio in one terminal
3. record on rt711 in another terminal.
   But if I stop playing, the headset MIC switch will turn off after a few seconds.

The problem is with the HW CBJ detection mode, the audio splitter will be detected as headphone(jack_type=0x1) not headset(jack_type=0x3).

The audio splitter we used has 4 rings. Any workarounds we can apply?

[keqiaozhang]

Thanks @bardliao and @aiChaoSONG
We have found a workaround to solve our problem, just connect one channel Line-out to USB sound card, then JD will recognize both headset and headphone. I can't explain the specific principle, it may be related to electrical or impedance.

[plbossart]

@bardliao @keqiaozhang can we close this bug? Is the work-around is good enough?

[keqiaozhang]

Linux#4687 was fixed by PR#4769. Now we can check this issue on rt711 SDW platforms.

It seems that above workaround cannot completely solve this issue, and we still occasionally reproduce this issue. We need a more robust solution.

[plbossart]

@bardliao @ssavati @marc-hb @fredoh9 this is one of the possible issues impacting our alsa-bat tests on RVPs connected to AIOC. I don't fully understand the issue but if we all use different analog connectors the results could vary in unpredictable ways.

[bardliao]

I checked 'Headset Mic Jack' status of all 3 MTLP_SDW_AIOC devices in JF, and they are all on.

amixer cget numid=37
numid=37,iface=CARD,name='Headset Mic Jack'
  ; type=BOOLEAN,access=r-------,values=1
  : values=on

So, the headset mic is detected.

[marc-hb]

Follow-up from thesofproject/sof#9018 (comment)

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

Two weeks later today, I spent more time testing a larger range of headphones and headsets (excluding the bad one I used 2 weeks ago!) and I'm finally confident I have really isolated and confirmed the issue: the detection reliability issue happens indeed only with a splitter BUT it's not because of the splitters! It's because we connect a LINE OUT to the RVP's microphone input. That very likely changes the impedance and makes the microphone detection unreliable simply because it is NOT a microphone that is connected! QED.

I'm confident this is the issue because I plugged and unplugged various jacks literally hundreds of times. The detection is rock solid EXCEPT when connecting a LINE OUT to the RVP's microphone input - thanks to the splitter, which I think is not itself an issue.

• When I disconnect the UCA-222 from USB which powers it off, then detection becomes reliable again.
• Disconnecting the microphone "half" of the splitter from the (powered) UCA-222, is also enough to make the detection become reliable again.

Why did this work before LNL? Probably thanks to: luck. Which just ran out.

[marc-hb]

I found that the detected_mode in the kernel logs is a bit "sticky". In other words, the next detected_mode line in the kernel logs is much more likely to be identical to the previous value. In the example below, detected_mode is 0x3 about 60% of the time and 0x5 about 40% of the time. BUT you can see that mode flips (also visible in evtest) are much less frequent than if the values were purely 60%/40% random.

Warning this test was WITHOUT actually unplugging the jack; merely power cycling the DSP instead. But I feel like a similar thing happened when I was actually unplugging yesterday.

This was also on a fresh boot, WITHOUT using 'rt711 GE49 Selected Mode' at all.

This "stickiness" was also observed in test failures: very often all failed or all passed.

ubuntu@jf-lnlm-rvp-sdw-1:~$ while aplay -s 1 /dev/zero ; do sleep 6; done &

# White lines added for better readability
ubuntu@jf-lnlm-rvp-sdw-1:~$ sudo journalctl -b -g detected_mode=0

May 17 20:56:55 jf-lnlm-rvp-sdw-1 kernel: Linux version 6.9.0-rc5-gcc7dc72bcaae ([email protected]) 
     (gcc (Ubuntu 11.4.0-2ubuntu1~20.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) 
       #dev SMP PREEMPT_DYNAMIC Tue May 14 06:02:04 PDT 2024


May 17 20:56:56  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:04:20  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:04:25  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:04:31  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:04:37  rt711_sdca_headset_detect, detected_mode=0x3

May 17 21:04:42  rt711_sdca_headset_detect, detected_mode=0x5

May 17 21:04:48  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:04:53  rt711_sdca_headset_detect, detected_mode=0x3

May 17 21:04:59  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:05:05  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:05:10  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:05:16  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:05:21  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:05:27  rt711_sdca_headset_detect, detected_mode=0x5

May 17 21:05:33  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:05:38  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:05:44  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:05:50  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:05:55  rt711_sdca_headset_detect, detected_mode=0x3

May 17 21:06:01  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:06:10  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:06:21  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:06:31  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:06:42  rt711_sdca_headset_detect, detected_mode=0x5

May 17 21:06:53  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:07:03  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:07:14  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:07:25  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:08:01  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:08:12  rt711_sdca_headset_detect, detected_mode=0x3

May 17 21:08:22  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:08:33  rt711_sdca_headset_detect, detected_mode=0x5

May 17 21:08:44  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:08:54  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:09:05  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:09:20  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:10:08  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:10:14  rt711_sdca_headset_detect, detected_mode=0x3

May 17 21:10:21  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:10:28  rt711_sdca_headset_detect, detected_mode=0x5

May 17 21:10:34  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:10:41  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:10:48  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:10:54  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:11:01  rt711_sdca_headset_detect, detected_mode=0x3

May 17 21:11:07  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:11:14  rt711_sdca_headset_detect, detected_mode=0x5
May 17 21:11:21  rt711_sdca_headset_detect, detected_mode=0x5

May 17 21:11:27  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:11:34  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:11:41  rt711_sdca_headset_detect, detected_mode=0x3
May 17 21:11:47  rt711_sdca_headset_detect, detected_mode=0x3

[marc-hb]

I re-tested many manual insertions on commit fbf0b7b, after fixup #4996 from @shumingfan was merged. Great news: everything works as expected!

Another good news: alsabat capture tests passed in daily test run https://sof-ci.ostc.intel.com/#/result/planresultdetail/41346 with that same commit. There were a lot of other failures on ba-lnlm-rvp-sdw-03 in that test run and then it crashed and hung forever but that does not seem related (will investigate. EDIT: rtcwake, see below).

@plbossart I can confirm that "None" below actually means "Autodetect". It does NOT mean "no jack" as I suspect you believed. Maybe the "None" word should be changed.

Note setting the value back to 0 didn't work before the fixup, it had no effect. Now after the fixup, cset 0 does restore the auto-detection default as most users would expect.

amixer -c sofsoundwire cget name='rt711 GE49 Selected Mode'
numid=8,iface=MIXER,name='rt711 GE49 Selected Mode'
  ; type=ENUMERATED,access=rw------,values=1,items=3
  ; Item #0 'None'
  ; Item #1 'Headphone'
  ; Item #2 'Headset'
  : values=0

But I feel like a similar thing happened when I was actually unplugging yesterday.

The auto-detection "stickiness" of the splitter+lineout is confirmed with manual tests. It randomly flips between headphone and headset but the previous value is much more likely.

[marc-hb]

Only one "signal too weak" failure in daily test run 41404?model=LNLM_SDW_AIOC&testcase=check-alsabat-headset-capture-599, see logs below.

EDIT: also in https://sof-ci.01.org/sofpr/PR9159/build4831/devicetest/index.html?model=LNLM_SDW_AIOC&testcase=check-alsabat-headset-capture-821

All other alsabat capture tests passed on the same run and system. In that failure the detected_mode was 0x5 / headset thanks to the "Selected Mode" kcontrol workaround.

There were a lot of other failures on ba-lnlm-rvp-sdw-03 in that test run and then it crashed and hung forever but that does not seem related (will investigate).

Same device was fine today, no idea why yet.

2024-05-22 14:27:58 UTC [REMOTE_COMMAND] alsabat -Phw:CODEC,0 --standalone -n 240000 -r 48000 -c 2 -f S16_LE -F 599 -k 2.1
2024-05-22 14:27:59 UTC [REMOTE_COMMAND] alsabat -Chw:sofsoundwire,1 -c 2 -r 48000 -f S16_LE -F 599 -k 2.1
WARNING: Signal too weak!
 FAIL: Peak freq too low 7.32 Hz
 FAIL: Peak freq too low 13.18 Hz
 FAIL: Peak freq too low 16.11 Hz
 FAIL: Peak freq too low 17.58 Hz
 FAIL: Peak freq too low 24.90 Hz
 FAIL: Peak freq too low 42.48 Hz
 FAIL: Peak freq too low 56.40 Hz
 FAIL: Peak freq too low 65.19 Hz
 FAIL: Peak freq too low 68.12 Hz
 FAIL: Peak freq too low 71.04 Hz
alsa-utils version 1.2.6

Entering capture thread (ALSA).
Get period size: 3000  buffer size: 24000
Recording ...
Capture completed.

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

Channel 1 - Checking for target frequency 599.00 Hz
Amplitude: 1.1; Percentage: [0]
Detected peak at 7.32 Hz of 3.97 dB
 Total 4.0 dB from 7.32 to 7.32 Hz
Detected peak at 13.18 Hz of 4.88 dB
 Total 9.1 dB from 13.18 to 13.92 Hz
Detected peak at 16.11 Hz of 4.13 dB
 Total 10.3 dB from 16.11 to 16.11 Hz
Detected peak at 17.58 Hz of 8.03 dB
 Total 12.3 dB from 17.58 to 17.58 Hz
Detected peak at 24.90 Hz of 9.65 dB
 Total 19.1 dB from 19.78 to 27.10 Hz
Detected peak at 42.48 Hz of 11.11 dB
 Total 25.1 dB from 29.30 to 53.47 Hz
Detected peak at 56.40 Hz of 10.20 dB
 Total 25.8 dB from 55.66 to 60.79 Hz
Detected peak at 65.19 Hz of 9.45 dB
 Total 26.3 dB from 62.26 to 66.65 Hz
Detected peak at 68.12 Hz of 10.30 dB
 Total 26.5 dB from 68.12 to 69.58 Hz
Detected peak at 71.04 Hz of 7.98 dB
 Total 26.6 dB from 71.04 to 71.78 Hz
Detected at least 10 signal(s) in total

Return value is -1003

[marc-hb]

As the "Selected Mode" workaround seems solid, I think we can finally close this?

[marc-hb]

There were a lot of other failures on ba-lnlm-rvp-sdw-03 in that test run and then it crashed and hung forever but that does not seem related (will investigate).

It crashed on rtcwake. This is pretty common, we noticed it only because ba-lnlm-rvp-sdw-03 does not have a remote PDU yet. So nothing unusual to worry about.

May 21 14:20:36 ba-lnlm-rvp-sdw-03 sudo[16629]:   ubuntu : PWD=/home/ubuntu ; USER=root ;
  COMMAND=/usr/bin/env PATH=/home/ubuntu/sof-test/tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin rtcwake -m mem -s 5
May 21 14:20:36 ba-lnlm-rvp-sdw-03 sudo[16629]: pam_unix(sudo:session):
   session opened for user root(uid=0) by (uid=1000)

End of logs; stuck for hours until manually rebooted by @ssavati

Off topic sorry.