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

[plbossart]

@phocean could you provide a screenshot of what the waveform looks like? You can do this with audacity and screenshot. Thanks!

@singalsu @juimonen @kv2019i FYI

[phocean]

@plbossart here it is:

Let me know if I can help further.

[plbossart]

@singalsu do we have a means to disable DC offset and ramps on the DMIC? Wondering if something goes in the weeds here.

[plbossart]

@phocean Can you make sure all switches are on in alsamixer (nothing odd muted).

Also wondering if the information on DMIC is actually correct. Can you add this in /etc/modprobe.d/hda-legacy.conf

options snd_intel_dspcfg dsp_driver=1

If the mic works with this, it means that you don't have a DMIC and your BIOS is incorrect. It's a long shot but we need to double-check this.

[phocean]

@plbossart For sure nothing has never been muted on the side of alsamixer, that something I checked multiple times and in all possible ways.

options snd_intel_dspcfg dsp_driver=1 does not seem to change anything.

[plbossart]

@phocean could you try the updated firmware 1.6 (https://github.com/thesofproject/sof-bin/tree/stable-v1.6)? It's a long shot but worth double-checking. Make sure you save /lib/firmware before installing stuff.

[phocean]

@plbossart sorry for the late answer. I just tested it but no change so far...

[singalsu]

@phocean Do you still have the wav file from above recording left to attach it here? I'd like to take a closer look to what it contains (noise or perfect digital silence). Or preferably make a new recording with check done that there's nothing private accidentally recorded.

I wonder if the capture gain just very low. Those power-on start transients can correspond to jet fighter loudness like noises of real world and they are in some platforms mitigated in firmware with volume ramp and IIR filter tricks.

[phocean]

@singalsu Here it is:

Clip 3.zip

Is that ok if it's an ogg file ?

[paulstelian97]

@singalsu Here it is:

Clip 3.zip

Is that ok if it's an ogg file ?

If it's an obviously audible issue yes. But for sound distortions we would need .wav to be able to fully understand the nature of the distortion. If it's no sound at all then ogg is okay. I recommend you get a .wav as well, just in case. (and it should be recorded as .wav, NOT just converting the ogg to wav)

[phocean]

That should be better (recorded with arecord -vv -fdat issue.wav) :

issue.zip

[plbossart]

@phocean we have reports of configuration issues related to DMICs, wondering if you are in the same case as https://github.com/thesofproject/linux/issues/2551 with non-existent microphones.

Can you provide the NHLT table or run the script suggested in https://github.com/thesofproject/sof-test/pull/488?

[phocean]

@plbossart

Is that helpful?

❯ sudo ./nhlt-parse.py
NHLT 1 endpoints
Link(DescriptorLength=6108, LinkType=2, InstanceID=0, VendorID=32902, DeviceID=44576, RevID=1, SubsystemID=1, DevType=1, Direction=1, VirtualBusId=0)
NHLT link type PDM
NHLT SPECIFIC_CONFIG size 3
NHLT FORMAT CONFIGS 2
NHTL: 1 dmics described

[singalsu]

@phocean we have reports of configuration issues related to DMICs, wondering if you are in the same case as #2551 with non-existent microphones.

Can you provide the NHLT table or run the script suggested in thesofproject/sof-test#488?

I checked the wav file (thanks for doing the capture). It looks similar to case when no digital microphones connected or not powered.

[phocean]

It does have a mic:

https://download.lenovo.com/consumer/mobiles_pub/thinkbook_13s-14s_iwl_hmm_201905.pdf

[singalsu]

Yep, there's such in the document but no info what type of microphone it is. Has the microphone worked with your device with Windows OS, if it was shipped with it pre-installed? If it would be my device I'd open it and check the mic flex cable is properly in connector but unless familiar with electronics assembly it's a task for service. A similar known working device could be tried with a live-Ubuntu 20.04 image if you would happen to know someone who could try.

[phocean]

I went through the process of creating a Windows USB drive this morning and booting on it.

At first, it missed the sound drivers, but after installing them, it worked flawlessly.

So this is definitely not a hardware issue, but missing support in Linux.

The sound drivers can be found there.

[singalsu]

Thanks @phocean , good test. @plbossart Do you know if anyone in our team has this device?

[singalsu]

@phocean Still a stretch and likely stupid question, did you try to capture from hw:0,0 "HDA Analog" ? In my CML NuC the analog microphones in the front panel appear at that device.

Edit: hw:1,0 in your device apparently.

[phocean]

@singalsu Sorry but I don't know how to test it. As for devices, I only see "sof-hda-dsp".

[singalsu]

Above shows that you have

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

If that's still card number 1 (usually it's 0) the capture line would be:

arecord -vvv -Dhw:1,0 -f dat -d 10 rec.wav The -vvv gives an ASCII "vu-meter"

[plbossart]

@phocean we are trying to determine where the microphones are connected

• to HDaudio codec (handled by codec driver)
• or directly to the PCH (handled by SOF firmware/driver)

[phocean]

Ok, thanks.

The result is that it gets no sound at all with the internal mic, but it would record normally with a headset plugged.

And with value 0, it says "invalid value for card".

[singalsu]

I think we need this device or find out otherwise (contact Lenovo) if the microphone clock or power connections differ from usual. If you are still OK to test more, please try to copy sof-hda-generic-4ch.tplg over sof-hda-generic-2ch.tplg and sof-hda-generic-1ch.tplg. Make backup of of those files to restore or reinstall the SOF binaries after test. Also kill of pulseaudio and temporary rename to /usr/bin/pulseaudio.disabled would be good. The rename is needed to prevent it from started again.

With 4ch DMIC configuration in place the record command would be:

arecord -Dhw:1,6 -f dat -c 4 -d 10 rec.wav

The result will be a 4ch wav file. If the microphone in your device would be clocked via channels 3-4 clock this could work. But e.g. if the microphones powering is unusual this won't help. You could try also simultaneously from other shell window the previous analog microphone record test (if codec and microphone would be for some reason from same Vdd).

[singalsu]

Also, is there a microphone mute function key in the device (F4 in my ThinkPad). Try to toggle it while recording.

[singalsu]

Also into list of faint ideas to try, with the 4ch topology. Try to start camera with e.g. application "Cheese". If the microphone would share the power with camera.

[phocean]

Should I reboot after overwriting the firmware files ?

I didn't and nothing changes after following all your suggestions: still no capture except the high pitch noise at the begining.

[paulstelian97]

Should I reboot after overwriting the firmware files ?

I didn't and nothing changes after following all your suggestions: still no capture except the high pitch noise at the begining.

The other way is to rmmod and insmod SOF so that it loads the new files instead of the old ones. But yes, the simplest way is rebooting.

[phocean]

Ok, it works that way !

Normally, I would get:

> arecord -vv -Dhw:1,6 -f dat -c 4 -d 10 rec.wav
Recording WAVE 'rec3.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 4
arecord: set_params:1349: Channels count non available

It would start with only 2 channels but recording no sound:

arecord -vv -Dhw:1,6 -f dat -c 2 -d 10 rec.wav

After overwriting the files, it works flawlessly.

What does it mean ? Can I do something to keep this configuration to work ?

[paulstelian97]

I think you can mark the linux-firmware package on hold until the next release of the firmware is out and ready.

[phocean]

@paulstelian97 No, because even if the microphone works, everything else (speakers) is broken. What are these files and what kind of hack can I do to have both the mic and the speakers to work?

[singalsu]

The topology overwrite should not impact playback. There's difference only in DMIC configuration in those topologies. Did you disable pulseaudio by renaming it? Then renaming (back to /usr/bin/pulseaudio and reboot) should bring you back the speakers.

Since this helped it looks like in your device the microphones are clocked via channels 3-4 HW. Are there any DMIC pins related settings in the BIOS that could change this to normal (via GPIO pins muxing)?

We'd really need to get a device like this. If confirmed the driver should support mode to enable only channels 1-2 but start all clocks. Currently there's no such so all channels need to be captured even if there's less connected microphones in the device.

[phocean]

Of course, I set pulseaudio back. I really loose the sound after the operation. Pulseaudio does not find any device and set a virtual device.

Regarding the PINS, there isn't such a setting in the BIOS (which is very similar to Thinkpad BIOS).

[singalsu]

@juimonen Do you know if pulseaudio version used can somehow break (speakers) from mic channels count increased from 2 to 4?

[juimonen]

@phocean can you attach here a recording from the arecord (with some audio to the mics) so we could see what channels get occupied? Also pulseaudio starting log would be good.

[gbrdead]

I am willing to take the role of a reporter. I have the same laptop (presumably).

I am using Debian Testing.

1. If the package firmware-sof-signed is not installed then there is no sound card detected.

2. After I installed firmware-sof-signed (https://packages.debian.org/bullseye/firmware-sof-signed), output worked fine but the microphone did not record any sound.

3. After I copied /lib/firmware/intel/sof-tplg-v1.6.1/sof-hda-generic-4ch.tplg over sof-hda-generic-2ch.tplg and restarted (without disabling pulseaudio), the following command:

arecord -vv -Dhw:0,7 -f dat -c 4 rec.wav

produced the first evidence after half an year that this computer actually has a microphone inside! Here is the file: https://www.voidland.org/.mic/rec.wav . The noise in the beginning is not from me, of course.

Here is the output of arecord -l:

card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

How can I make a GUI application (e.g. firefox) to use hw0,7? I am using KDE.

[gbrdead]

How can I make a GUI application (e.g. firefox) to use hw0,7? I am using KDE.

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

2. Restart and use the input named "Comet Lake PCH-LP cAVS" (without "Multichannel") in KMix.

[paulstelian97]

3. After I copied /lib/firmware/intel/sof-tplg-v1.6.1/sof-hda-generic-4ch.tplg over sof-hda-generic-2ch.tplg and restarted (without disabling pulseaudio), the following command:

arecord -vv -Dhw:0,7 -f dat -c 4 rec.wav

produced the first evidence after half an year that this computer actually has a microphone inside! Here is the file: https://www.voidland.org/.mic/rec.wav . The noise in the beginning is not from me, of course.

Yikes that's a long codec initialization time (for the noise part).

@juimonen Any clue how to compensate for the fact that this noise exists? @singalsu Does the volume component have an adjustable startup delay/volume curve?

[singalsu]

@gbrdead Seems that your device has two microphones those are connected to channels 3 and 4. There's no microphone in channels 1 and 2 and the not-connected microphones create the start transient that's seen. (non-toggling PDM bus appears as full scale DC and then the stepped HW gain ramp and high-pass create the effect seen)

Device hw:0.7 gives 16 kHz sampled audio, you should have same success with hw:0,6 that is configured for 48 kHz. The start transient is longer for 16 kHz mode. There may be a way to improve it (move start transient mitigation totally to FW side since the HW mitigation settles quite slow) but please use the primary 48 kHz device if that works for you.

I need to test if accessing ch3-4 connected microphones can be fixed with a custom topology to appear as normal 2ch device. But since the BIOS information for microphones is incorrect for this device it won't owrk out-of-box. There will be need to copy the custom topology over the sof-hda-generic-2ch.tplg.

[singalsu]

Based on the observation I created this pull request https://github.com/thesofproject/sof/pull/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.

[kv2019i]

@gbrdead To make the topology selection automatic, can you help to capture the full NHLT dump from the laptop in question:

sudo cat /sys/firmware/acpi/tables/NHLT >NHLT.bin

... and attach "NHLT.bin" to this bug. If the FW fix in https://github.com/thesofproject/linux/issues/2460#issuecomment-779212719 help, we need to figure out how the kernel could automatically load this topology on affected systems. We basicly have two options: 1) we add an exception based on DMI name to soc-acpi-intel-cml-match.c (each affected product listed separately), or 2) if the routing is visible in NHLT data, we could have generic logic that works on all systems where BIOS can describe the configuration

FYI for @plbossart

[gbrdead]

The microphone works much better with the patched topology:

1. Higher volume and sensitivity.
2. No noise in the beginning of the recording.

The modification to /etc/pulse/default.pa is still necessary for audacity et al.

NHLT.zip

[singalsu]

@gbrdead Nice that it worked, now the low-level fix is known and need to figure out how to solve the upper level things. Can you still describe what is the issue with 48 kHz hw:0,6 device. Is the sound muted? Do you get errors from arecord?

The gains can be set via command line and alsamixer for 48 kHz device

$ amixer cset name='Dmic0 Capture Volume' 50,50
numid=49,iface=MIXER,name='Dmic0 Capture Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=70,step=0
  : values=50,50
  | dBscale-min=-50.00dB,step=1.00dB,mute=1

$ amixer cset name='Dmic0 Capture Switch' on,on
numid=50,iface=MIXER,name='Dmic0 Capture Switch'
  ; type=BOOLEAN,access=rw------,values=2
  : values=on,on

For 16 kHz device there's control

$ amixer cset name='Dmic1 2nd Capture Volume' 50,50
numid=52,iface=MIXER,name='Dmic1 2nd Capture Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=70,step=0
  : values=50,50
  | dBscale-min=-50.00dB,step=1.00dB,mute=1

[gbrdead]

Both hw:0,6 and hw0,7 work well with the patched topology.

[plbossart]

1. we add an exception based on DMI name to soc-acpi-intel-cml-match.c (each affected product listed separately), or
2. if the routing is visible in NHLT data, we could have generic logic that works on all systems where BIOS can describe the configuration

I re-checked the NHLT document: https://01.org/sites/default/files/595976_intel_sst_nhlt.pdf

I don't see anything that would tell us how the microphones are connected. I only see channels and mic array geometry, nothing on which PDM wires are used.

It probably works in Windows because the mic configuration is hidden in binary blobs, so there's nothing that's exposed. It's actually a good example of missing information, the only way by which we could select the topology dynamically would be by parsing NHLT blobs.

Instead of a topology switch, could we alternatively have a Kcontrol?

[singalsu]

@plbossart This can be decoded from binary part of the blob, the blob that was shared here has the FIFO packer set up differently than in various 2ch NHLTs we quickly collected with @kv2019i , also we checked that 4ch can be detected from there. The PCM data FIFOs source is set to pdm1 instead of normal pdm0 in Thinkbook13S. It's then another matter if want to to decode this in the driver since we have different revisions of HW and the needed bit-fields to decode.

[plbossart]

@singalsu do we only have 2 configurations for 2ch?

Also what would happen e.g. in the 1ch case, would we need to provide 4 topologies?

[singalsu]

@plbossart Yep, the same connection issue can be made with single microphone. So with the naming that I used in my SOF PR there could be need for sof-hda-generic-1ch-pdm1.tplg too.

[plbossart]

@plbossart Yep, the same connection issue can be made with single microphone. So with the naming that I used in my SOF PR there could be need for sof-hda-generic-1ch-pdm1.tplg too.

how would we pick ch0 or ch1 on that link though?

[singalsu]

@plbossart There's no need to select ch0 or ch1 in mono case, the single microphone data appears on both slots. It's available in firmware IPC (swapped mono) but it's not used currently.

We don't actually use mono PCM format for 1ch dmic. The capture data appears with the current topologies as dual mono. There's an unsolved DMA configuration issue with mono DMIC data.