Hey all, hoping someone’s run into this specific board before.
Laptop is an ASUS VivoBook X509DA/M509DA (Ryzen 3000 “Picasso” APU). Mic shows up fine in every tool, capture stream opens without errors, but recordings are either dead silent or pure static depending on settings. Codec is Realtek ALC256 (10ec0256, subsystem 1043197e).
Turns out the codec exposes two separate “internal mic” pins:
Simple mixer control 'Internal Mic',0 <- kernel default, this one is bad/noisy
Simple mixer control 'Internal Mic 1',0 <- this one is the actual working mic
dmesg confirms the kernel just picks a generic fallback fixup instead of a proper quirk for this board:
snd_hda_codec_alc269 hdaudioC1D0: ALC256: picked fixup (pin match)
If I manually flip the ALSA capture source mux to item 2 (“Internal Mic 1”) and bump its boost, recording actually works fine at the raw ALSA level:
amixer -c 1 cset numid=6 2
amixer -c 1 cset numid=11 2
Problem is PipeWire/WirePlumber never picks this up, pavucontrol still shows/uses the wrong internal mic port regardless, since ACP only exposes a single “Internal Microphone” port mapped to the kernel’s default (wrong) pin. It’s not that something actively reverts my amixer change, more that PipeWire’s ACP layer has no concept of the second pin existing or something at all, so nothing downstream ever reflects it.
I tried a snd-hda-intel model= quirk (headset-mic, dell-headset-multi) via boot.extraModprobeConfig, no effect, dmesg still shows the generic “pin match” fixup, so this board apparently isn’t in the per-model quirk table at all.
Found an Arch thread with the identical symptom on the exact same codec/mixer controls (different board, Tiger Lake though) that got solved with a model quirk, but that path’s a dead end for me since nothing in the table matches this subsystem ID.
Anyone dealt with ALC256 + ASUS AMD boards specifically, or know if there’s an existing upstream quirk I should be requesting instead of hacking around it locally?
Happy to post full alsa-info.sh output if useful.