https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298365
Bug ID: 298365
Summary: snd_hda(4):AL internal difital mic (mid18) enumerates
but captures silence on Thinkpad T490
Product: Base System
Version: 15.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Created attachment 274600
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=274600&action=edit
sysctl and dmesg output
FreeBSD version: <paste output of: uname -a>
Hardware: Lenovo ThinkPad T490 (LENOVO TP-N2I)
Codec: Realtek ALC257, vendor=0x10ec device=0x0257, subsystem 0x17aa2279
Controller: Intel Cannon Lake HDA (vendor=0x8086 device=0x9dc8)
The internal microphone enumerates correctly but records only silence.
nid18 is the internal mic:
Pin config: 0x90a60120 as=2 seq=0 device=Mic conn=Fixed ctype=Digital
loc=Internal
Pin cap: 0x00000020 IN
Pin control: 0x00000020 IN
Input amp: mute=0, +0/+30dB
Routed nid18 -> nid36 (selector) -> nid7 (audio input)
Exposed on pcm0 as OSS "monitor"
pcm0 is <Realtek ALC257 (Analog 2.0+HP/2.0)>, location nid=20,33,18, with a
working record channel.
Steps taken:
mixer -f /dev/mixer0 monitor.recsrc=set
mixer -f /dev/mixer0 monitor.volume=0.9
dd if=/dev/dsp0 of=/tmp/mic.raw bs=8k count=100
Result: capture completes at full rate; playback of the raw file is silent.
nid18 reports pin cap 0x00000020 (IN only) with no VREF bits, so the ivref50 /
ivref80 / ivref100 hints in dev.hdaa.0.config have no effect. Pin control never
changes from 0x00000020.
By contrast nid25 (Mic, Black Jack, loc=Right, pin cap 0x00003724 with
VREF[50 80 100 GROUND HIZ]) works normally as pcm1 with a headset connected.
Speakers (nid20), headphones (nid33) and HDMI audio (pcm2) all function.
ctype=Digital on nid18 indicates a DMIC. Linux enables this path via Realtek
vendor coefficient writes in sound/pci/hda/patch_realtek.c; hdaa(4) has no
equivalent handling for ALC257, so the mic is never clocked despite correct
enumeration and routing.
Also noted: dev.hdaa.0.reconfig=1 consistently reports "0 -> 0" and does not
re-enumerate.
Full sysctl and dmesg output attached.
--
You are receiving this mail because:
You are the assignee for the bug.