Microphone not working (Lenovo Thinkbook 13S, CML-U)

[phocean]

The microphone is not working with my laptop : Lenovo Thinkbook 13S.

Distribution : openSUSE Tumbleweed (20200829)

~ ❯ uname -a
Linux thinkpad 5.8.4-1-default #1 SMP Wed Aug 26 10:53:09 UTC 2020 (64fe492) x86_64 x86_64 x86_64 GNU/Linux

~ ❯ inxi -A                               
Audio:
  Device-1: Intel driver: sof-audio-pci 
  Sound Server: ALSA v: k5.8.4-1-default 

~ ❯ dmesg | grep snd
[   13.184060] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[   13.184064] snd_hda_intel 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
[   13.649953] snd_soc_skl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[   13.649957] snd_soc_skl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
[   14.062251] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC257: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   14.062254] snd_hda_codec_realtek ehdaudio0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   14.062256] snd_hda_codec_realtek ehdaudio0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[   14.062258] snd_hda_codec_realtek ehdaudio0D0:    mono: mono_out=0x0
[   14.062259] snd_hda_codec_realtek ehdaudio0D0:    inputs:
[   14.062261] snd_hda_codec_realtek ehdaudio0D0:      Mic=0x19
[   14.108320] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten
[   14.108327] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten
[   14.108400] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> DMIC 6 mapping ok
[   14.108408] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> DMIC16kHz 7 mapping ok
[   14.108421] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDA Analog 0 mapping ok
[   14.108433] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDA Digital 1 mapping ok
[   14.108442] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDMI1 3 mapping ok
[   14.108449] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDMI2 4 mapping ok
[   14.108459] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDMI3 5 mapping ok

Using arecord results in no sound, except a high pitch noise that last less than 1 sec at the begining.

/tmp ❯ arecord -l
**** Liste des Périphériques Matériels CAPTURE ****
carte 1: sofhdadsp [sof-hda-dsp], périphérique 0: HDA Analog (*) []
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: sofhdadsp [sof-hda-dsp], périphérique 1: HDA Digital (*) []
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: sofhdadsp [sof-hda-dsp], périphérique 6: DMIC (*) []
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0
carte 1: sofhdadsp [sof-hda-dsp], périphérique 7: DMIC16kHz (*) []
  Sous-périphériques: 1/1
  Sous-périphérique #0: subdevice #0

/tmp ❯ arecord -Dhw:1,6 -c2 -r48000 -fS32_LE -d 10 mytest.wav
Capture WAVE 'mytest.wav' : Signed 32 bit Little Endian, Fréquence 48000 Hz, Stéréo

^CInterrompu par le signal Interrupt...

/tmp 7s ❯ open mytest.wav

Attachments:

alsa-info.txt

dmesg.txt Downstream bug report

[shining]

I managed to do this:

1. Add the following two lines in `/etc/pulse/default.pa`:

load-module module-alsa-source device=hw:0,7
set-default-source alsa_input.hw_0_7

Hello,

We have the following device on Levono P14s :

00:1f.3 Audio device [0403]: Intel Corporation Comet Lake PCH-LP cAVS [8086:02c8] (prog-if 80)

The internal mic works almost out of the box on Archlinux with kernel 5.11, after installing the sof firmware 1.7.

On Debian 10, it required more steps :

1. installing 5.10 kernel from backport + sof firmware 1.6 from testing (or even the last 1.7 version manually, not sure)
2. options snd-intel-dspcfg dsp_driver=3 to select SOF
3. make hw_0_7 the default like suggested above (or hw_0_6?)

Could anyone explain why steps 2 and 3 are needed on Debian, and how comes it work out of the box on Archlinux ?

Also it looks like we lost the HDMI output option after step 3.

Thanks a lot for the help.

[plbossart]

On Debian 10, it required more steps :

1. installing 5.10 kernel from backport + sof firmware 1.6 from testing (or even the last 1.7 version manually, not sure)
2. options snd-intel-dspcfg dsp_driver=3 to select SOF
3. make hw_0_7 the default like suggested above (or hw_0_6?)

Could anyone explain why steps 2 and 3 are needed on Debian, and how comes it work out of the box on Archlinux ?

no idea @shining, the autodetection of SOF should work the same. Assuming that you are testing the two distros on the SAME hardware, we should use the same information to select SOF v. legacy HDaudio.

Please try without step2 and provide the detailed dmesg log with the following file added to /etc/modprobe.d/sof-dyndbg.conf sof-dyndbg.conf.txt

[shining]

It was two laptops from my colleagues that should have exactly the same specs. I just received mine which comes with Windows 10 preinstalled. Is there anything useful to get from it (firmware and stuff) before replacing it by Debian ?

[paulstelian97]

It was two laptops from my colleagues that should have exactly the same specs. I just received mine which comes with Windows 10 preinstalled. Is there anything useful to get from it (firmware and stuff) before replacing it by Debian ?

Should just be able to install Debian directly. Ensure you have backup media (f.e. don't bust the recovery partition) so you can return to Windows in the future if you need to.

[Elinvynia]

Update from Fedora 34 which switches to pipewire and promises to fix some sound issues in the kernel: broken by default without the patched topology file mentioned above. Relevant fedora discussion: https://ask.fedoraproject.org/t/internal-microphone-does-not-work-on-thinkbook-13s-iml/12881/2

[shining]

On Debian 10, it required more steps :

1. installing 5.10 kernel from backport + sof firmware 1.6 from testing (or even the last 1.7 version manually, not sure)
2. options snd-intel-dspcfg dsp_driver=3 to select SOF
3. make hw_0_7 the default like suggested above (or hw_0_6?)

Could anyone explain why steps 2 and 3 are needed on Debian, and how comes it work out of the box on Archlinux ?

no idea @shining, the autodetection of SOF should work the same. Assuming that you are testing the two distros on the SAME hardware, we should use the same information to select SOF v. legacy HDaudio.

Please try without step2 and provide the detailed dmesg log with the following file added to /etc/modprobe.d/sof-dyndbg.conf sof-dyndbg.conf.txt

Looks like step 2 was not needed on my machine, so the autodetection of SOF works indeed.

What about step 3 ?

I still don't undestand what the HDA Analog and HDA Digital devices are for, and why there are 4 capture devices ?

On my other laptop there is only one recording device and it works :

**** List of CAPTURE Hardware Devices ****
card 1: PCH [HDA Intel PCH], device 0: ALC3232 Analog [ALC3232 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

[plbossart]

1. installing 5.10 kernel from backport + sof firmware 1.6 from testing (or even the last 1.7 version manually, not sure)
2. options snd-intel-dspcfg dsp_driver=3 to select SOF
3. make hw_0_7 the default like suggested above (or hw_0_6?)

Looks like step 2 was not needed on my machine, so the autodetection of SOF works indeed.

What about step 3 ?

I don't know what 'make hw_0_7' refers to. Never used it.

I still don't undestand what the HDA Analog and HDA Digital devices are for, and why there are 4 capture devices ?

Yes, that may be a bit confusing. Some HDaudio devices have an analog and a SPDIF digital output, but we can't know this at the SOF level. So we expose two separate streams, knowing that one of them may or may not work.

On my other laptop there is only one recording device and it works :

**** List of CAPTURE Hardware Devices ****
card 1: PCH [HDA Intel PCH], device 0: ALC3232 Analog [ALC3232 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Can you share more information on what the other recording devices are? e.g. share the results of alsa-info.

Also if you have a Lenovo Thinkbook 13S, as discussed above there is a configuration issue with a PDM0/PDM1 inversion that no one else has done, and that means that to get working audio you need to override the default topology file by the one shared above, see https://github.com/thesofproject/linux/issues/2460#issuecomment-779212719

[shining]

I don't know what 'make hw_0_7' refers to. Never used it.

See https://github.com/thesofproject/linux/issues/2460#issuecomment-778805723

Yes, that may be a bit confusing. Some HDaudio devices have an analog and a SPDIF digital output, but we can't know this at the SOF level. So we expose two separate streams, knowing that one of them may or may not work.

Ok so looks like you confirm that it's necessary to configure pulse default depending on the hardware for now ? No hope for a solution ?

Can you share more information on what the other recording devices are? e.g. share the results of alsa-info.

Exactly the same as in the first post, except it's card 0 and not card 1.

Also if you have a Lenovo Thinkbook 13S

It's a P14s, overriding the default topology file does not seem necessary.

alsa-info.txt.S6gge5ZXkr.gz sof-debug.log.gz

[plbossart]

I don't know what 'make hw_0_7' refers to. Never used it.

See #2460 (comment)

why is this necessary? if you use alsa-ucm-conf, you don't need to tweak PulseAudio. the Linux Arch information seems to be completely outdated.

Yes, that may be a bit confusing. Some HDaudio devices have an analog and a SPDIF digital output, but we can't know this at the SOF level. So we expose two separate streams, knowing that one of them may or may not work.

Ok so looks like you confirm that it's necessary to configure pulse default depending on the hardware for now ?

not at all, this information seems completely wrong. Device 0,7 is the DMIC at 16kHz, not the one you want at all

Your local mic is device hw:0,6 and the headset mic is device hw:0,0

card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog () [] card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC () []

No hope for a solution ?

well most folks have no issues with HDaudio + DMIC, we've worked hard to make it turn key and most likely your distro uses obsolete bits.

please see https://thesofproject.github.io/latest/getting_started/index.html#debug-audio-issues-on-intel-platforms to check for yourself what might be wrong.

[shining]

Yes, as I explained, this is on Debian 10. To get local mic working I already had to install kernel and sof firmware from testing (future Debian 11). alsa-ucm-conf also only exists in testing and this looks harder to backport.

So it's awesome if everything works well already with the future Debian 11, I will test it to confirm, and let's hope it will be released this year. But I would also would like to know what's the best workaround for Debian 10 for now.

What about the following then ?

load-module module-alsa-source device=hw:0,6
set-default-source alsa_input.hw_0_6

This will maybe force the local mic all the time, even when a headset mic is plugged ? But still a good workaround for now ?

In any cases, thanks a lot for the help, it's starting to be clearer, and thanks a lot for your work.

[shining]

I confirm it works well with Debian 11, without any hack. :+1:

The default mic switches from local mic to headset mic when I plug a headset and vice versa. This can be seen in pavucontrol or with the following command : pacmd list-sources | grep -e 'index:' -e device.string -e 'name:'

[sunweaver]

Based on the observation I created this pull request thesofproject/sof#3847 . @gbrdead Can you please try this topology:

sof-hda-generic-2ch-pdm1.zip

Unzip and copy sof-hda-generic-2ch-pdm1.tplg over /lib/firmware/intel/sof-tplg/sof-hda-generic-2ch.tplg. I just tested with my 4 mic device (Lenovo X1) that these commands captured microphones 3 and 4 as stereo.

arecord -Dhw:0,6 -f dat -d 10 rec06.wav
arecord -Dhw:0,7 -f dat -r 16000 -d 10 rec07.wav

Since alsamixer view changes from 4ch back to 2ch check that Dmic0 and Dmic1 gains and mute switches are sane.

@singalsu I just took your topology file and replaced sof-hda-generic-2ch.tplg on a freshly installed Debian 11 system. Test device is a Lenovo 13s (which my school customer has plenty of).

Without your topology file, the internal "Digital Microphone" is shown in Pulseaudio and alsamixer, but I cannot record sound with the internal mic. Neither do I see any input level in pavucontrol for the "Digital Microphone".

With your binary topology file offered for download further up in thesofproject/linux#2460, I can start using the microphone.

So for the Lenovo Thinkpad 13S, this bug is definitely still an issue in Debian 11.

About your PR, I saw that upstream closed the PR when renaming the "master" branch to "main" and it seems like noone ever cared about re-opening it.

So, I wonder what the status of this problem currently is in SOF upstream and how we (I am a Debian Developer) can get SOF HDA DSP working for the Lenovo Thinkpad 13S in Debian 11.

Thanks for your work on this! Looking forward to some extra info.

[plbossart]

@sunweaver the status has not changed: the SOF driver as currently implemented cannot know which PDM interface is used. Most platforms use PDM0 but Lenovo for some reason used PDM1. Unfortunately this information is set in the 'topology file' and we just don't know how to select this topology.

Rather than adding multiple topology files and try to figure out what platform needs what topology, we wanted to change the approach and instead of using the information stored in a topology file we could use the information provided in the platform firmware (DSDT/NHLT). I believe @singalsu did quite a bit of work on this already at the firmware level, this will hopefully come in a future SOF release.

[johnnrandall]

I've got a similar issue to @phocean above. My laptop is also a Thinkbook 13.

My outputs are below:

uname -a Linux lenovo 5.4.0-100-generic #113-Ubuntu SMP Thu Feb 3 18:43:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

inxi -A Audio: Device-1: Intel driver: sof-audio-pci Sound Server: ALSA v: k5.4.0-100-generic

dmesg | grep snd [ 4.973474] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [ 4.973699] snd_hda_intel 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [ 5.369091] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC257: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 5.369103] snd_hda_codec_realtek ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.369111] snd_hda_codec_realtek ehdaudio0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 5.369116] snd_hda_codec_realtek ehdaudio0D0: mono: mono_out=0x0 [ 5.369120] snd_hda_codec_realtek ehdaudio0D0: inputs: [ 5.369127] snd_hda_codec_realtek ehdaudio0D0: Mic=0x19 [ 5.417987] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten [ 5.418028] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten [ 5.419118] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> DMIC 6 mapping ok [ 5.419300] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> DMIC16kHz 7 mapping ok [ 5.419556] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDA Analog 0 mapping ok [ 5.419784] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDA Digital 1 mapping ok [ 5.419944] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDMI1 3 mapping ok [ 5.420100] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDMI2 4 mapping ok [ 5.420247] skl_hda_dsp_generic skl_hda_dsp_generic: snd-soc-dummy-dai <-> HDMI3 5 mapping ok

The headphone microphone works but the internal one has never shown any kind of input level.

Any assistance would be gratefully received.

[plbossart]

@johnnrandall "Linux lenovo 5.4.0-100-generic" is likely rather too old for proper SOF support. It's probably one of the first versions we upstreamed. Please consider updating your system if possible, it's very difficult to solve problems on kernels that are 12 versions old. Thanks for your understanding.

[johnnrandall]

Which kernel do you recommend? I've tried a more recent one but unfortunately that alone didn't resolve it which is why I reverted to this one.

[plbossart]

5.10+ is recommended.

The solution for Lenovo devices is to try to use the topology provided in https://github.com/thesofproject/linux/files/5981682/sof-hda-generic-2ch-pdm1.zip

Unzip and copy sof-hda-generic-2ch-pdm1.tplg over /lib/firmware/intel/sof-tplg/sof-hda-generic-2ch.tplg (KEEP THE INITIAL VERSION AS A BACKUP).

[johnnrandall]

I tried the link and followed the instructions. And yes it was the solution. I can hardly contain my thankfulness! On this basis I will stick with my current kernel unless you recommend otherwise. Thank you once again, and have a great evening.

[plbossart]

@johnnrandall glad it works for you. At some point we may be able to do this switch automagically but for now we have to override this topology file. You can update the kernel to a more recent version, it will not change anything. The one thing you need to watch out for is that distribution updates may override this file, so you may have to redo this override if the mic becomes silent again.

[plbossart]

There will be no magical solution to this problem, the only work-around is to load an alternate topology. This will be enabled starting with kernel 5.20 and SOF 2.3. see details of the documentation here: https://thesofproject.github.io/latest/getting_started/intel_debug/suggestions.html#digital-mic-issues

[unoexperto]

Folks, I'm on Lenovo T14 AMD Gen4. I don't have *.tplg files on the disk at all. Could you please advise what to do ?

My stats:

uname -a
Linux expert-thinkpad 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

inxi -A
Audio:
  Device-1: AMD Rembrandt Radeon High Definition Audio driver: snd_hda_intel
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor driver: snd_pci_acp6x
  Device-3: AMD Family 17h/19h HD Audio driver: snd_hda_intel
  API: ALSA v: k6.8.0-31-generic status: kernel-api
  Server-1: PipeWire v: 1.0.5 status: active

[plbossart]

@unoexperto that's a different platform, please file a separate issue for AMD to support