For a little while I used the model=dell-headset-multi solution from this post to get the headset mic working. But having “Headset Mic” and “Headphone Mic” devices, only one of which worked, annoyed me. So I read some docs and played around with hdajackretask and came up with something that seems to work somewhat better.
First, make sure your kernel is compiled with CONFIG_SND_HDA_PATCH_LOADER=y.
Create a patch file in /lib/firmware/hda-audio-patch.fw (the exact filename doesn’t matter), with contents
and your mixer should then show controls for both “Internal Mic” and “Mic”.
I also found a few other things:
If you add a line 0x1b 0x908001f0 to that hda-audio-patch.fw file, you’ll get a “Line” input alongside “Internal Mic” and “Mic”. This is something of a loopback, it lets you record the audio as it’s being output.
While BIOS can beep through the sound card, probably via a hardware pin, it doesn’t seem that there’s a “beep generator audio widget” on the Realtek ALC295 codec for Linux to use. Or if there is, it needs some magic (that no one seems to know about) to make it show up.
Hello, I have been having issues accessing the microphone on Arch Linux. I have booted into a live ISO of Ubuntu 21.04, on which the microphone worked. So I know it isn’t a hardware issue. I found this post, and tried it, but the microphone still isn’t showing up in pavucontrol. I do however see the kernel loading it (I think). After reloading the kernel module snd_hda_intel, I get this output in dmesg
It has the line of it applying the patch, but doesn’t have it direct-loading it. The devices seem to be in dmesg, but show up in neither pavucontrol or in pacmd list-sources.
@Seth_Gower Looks like the kernel is seeing it. The different loading message may be due to a different kernel version, or Debian (which I use) may have patched it for some reason.
You might start by tracking down where exactly it’s getting lost.
On my Debian system with kernel 5.14.9, I have a file /proc/asound/card0/codec#0 where I can see Node 0x12 is associated with “Internal Mic Boost Volume” and Node 0x19 is associated with “Mic Boost Volume”
Then I see amixer includes both “Simple mixer control ‘Mic’,0” and “Simple mixer control ‘Internal Mic’,0”. Similarly, I find Mic and Internal Mic in alsamixer.
I don’t use pulseaudio so I don’t know how you’d see what that’s doing with it.
Simple mixer control 'Master',0
Capabilities: pvolume pswitch pswitch-joined
Playback channels: Front Left - Front Right
Limits: Playback 0 - 65536
Mono:
Front Left: Playback 62265 [95%] [off]
Front Right: Playback 62265 [95%] [off]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch cswitch-joined
Capture channels: Front Left - Front Right
Limits: Capture 0 - 65536
Front Left: Capture 65536 [100%] [on]
Front Right: Capture 65536 [100%] [on]
Turns out I was wrong about that. It does have a beep generator “hidden” on nid 0x01.
What it doesn’t have is a way to control it via the HDA mixers, so Linux refuses to use it. The only way to make it work is apparently to set a secret register that makes it replace the (seemingly unused on Framework) 0x1a input, exactly as described in Realtek PC Beep Hidden Register — The Linux Kernel documentation.
if the output is
CONFIG_SND_HDA_PATCH_LOADER=y
then the flag was set.
I wouldn’t have replied to this old thread, but mic via jack is now important to me, maybe to others…
