Internal DMIC not working on ThinkPad T14 Gen 3 Intel (21AH) — Alder Lake / sof-hda-dsp

[ipillyx]

Device: Lenovo ThinkPad T14 Gen 3 (21AH00D7UK), i5/i7 Alder Lake
Audio: Intel Alder Lake PCH-P HDA controller (00:1f.3), Realtek ALC257 codec,
2x DMIC on the Intel DSP (NHLT reports 2 DMICs)
Brunch version / recovery image: Brunch r147 stable 20260513/Voxel/148.0.7778.250

Problem: Speakers and headphone jack work. Internal microphone is not
detected/captures nothing. USB and headset-jack mics work fine.

Expected driver path: snd_sof_pci_intel_tgl with sof-adl.ri firmware and
sof-hda-generic-2ch.tplg topology (verified working on Fedora, where the card
enumerates as sof-hda-dsp with Digital Microphone capture). The DMICs are DSP-attached,
so the legacy HDA path can't reach them — CRAS likely needs a UCM config for sof-hda-dsp.

[eduardorovieira]

I ran into this issue on a Samsung Galaxy Book 4 (Intel 13th Gen) running ChromeOS via Brunch.

In my case, the microphone hardware and drivers were actually working correctly. The problem was that CRAS was selecting the wrong input node as the default microphone during boot.

Symptoms:

• The internal microphone appears in ChromeOS settings.
• The microphone may appear as detected by ALSA and CRAS.
• Audio recording may work when using ALSA directly.
• Applications such as Google Meet, Recorder, or microphone tests only capture silence or noise.

How to diagnose:

1. Check the available CRAS input nodes:

cras_test_client --dump_server_info

Look under "Input Nodes".

2. Identify all available microphone inputs. On my system I had multiple inputs, including:

   • Internal Mic
   • DMIC
   • UNKNOWN devices

3. Test each input manually:

cras_test_client --select_input <device_id>:<node_id>

For example:

cras_test_client --select_input 12:0

4. After selecting a different input, test the microphone again in ChromeOS settings or a web application.

In my case, input 12:0 was the only node that actually captured audio correctly, even though ChromeOS kept selecting another microphone as the default.

How to verify the hardware is not the problem:

arecord -l

If you can see DMIC devices and record audio successfully using ALSA, the issue is likely not the kernel driver. It may simply be CRAS choosing the wrong input node.

Current workaround:

After every reboot I run:

cras_test_client --select_input 12:0

and the microphone immediately starts working.

At the moment I have not found a reliable way to make this selection persist across reboots on Brunch, but manually selecting the correct CRAS input node completely resolves the issue on my system.

Hopefully this helps others who have a working microphone that is being ignored because ChromeOS is choosing the wrong default input device.