To be fair, they moved quickly on it. I received notice from kernel maintainers that the patch landed in the branches for the next 6.6 and 6.1 kernel releases.
Fedora 39 now has 6.6.7-200.fc39.x86_64 on updates. Tested that everything works without the modules update. 15 day isn’t that bad for upstream kernel submission to Fedora distro kernel update. To be fair, it’s also a first time submission and a simple one a that. I hope it encourages others to contribute patches in the future.
Much appreciated effort @Tim_Bosse ![]()
I am using Fedora 42 on the Framework 13 with the AMD HX 370 and I’ve also been having issues with external mics not being recognised by alsa. Not even on a live USB with Ubuntu 24.04 or Fedora 42, so it’s not a software/configuration issue on my end.
I reached out to support and they sent me a new audio card. Replacing it caused no change, so it’s unlikely it’s a hardware issue. I also triple checked that this headset also works fine on my previous Thinkpad laptop still.
The external microphone in question is this one, which I use as a cable for a Phillips headset: V-Moda Boompro Microphone for Gaming & Communication - Black, wired - 3.5 mm Jack : Amazon.co.uk: PC & Video Games
Out of desperation, because I really need the external mic for work, I tried the workaround from earlier in this thread ([SOLVED] Headset Mic on AMD FW13 running Fedora 39 - #14 by James_Richards) and rebooted. To my surprise, the external mic works now! The internal mic stopped working now, but I can live with that as I don’t need it.
I have found my workaround but I would love to understand what’s going on. From my reading of the thread, Fedora 42 should contain a new enough kernel (and alsa, and pipewire, etc) so that no system tweaks need to be made for external mics to work. I should note that I also tested a USB mic and that always worked, so it’s just an issue with the jack port.
I’m using arch Linux on the new framework AMD 7 ai 350.
I have the same problem. The internal mic has too much gain. Settings the gain to 25% works fine.
The headphone microphone is not recognized. I’m able to listen audio from my 3.5 jack headphone but only the internal mic work and the one from the headphone in not recognized.
I don’t think that is and hardware issue. Right now for me is not a big issue so I didn’t test any workaround.
Please elaborate on the status of your internal (digital) microphone because I have the same issue on the same hardware
!
That is, my internal microphone on another new FW 13 with the AMD HX 370 also does not work. My external microphone works fine. The sound from the internal microphone is bad quality in Fedora 42 Live (running from a USB stick) and not working in Bluefin 41 GTS. Is your internal microphone in a SUSPENDED state?
I posted details on the Universal Blue discourse since the issue is worse on Bluefin GTS than on Fedora 42 Live:
Same issue here on an AI 9 HX 370, running NixOS and Pipewire for Audio
I’m also seeing the same issue with headset microphones not working on the AI 9 HX 370 with NixOS.
Applying the mentioned kernel module options for the snd-hda-intel kernel module has no effect. I think that this is only relevant for older kernels anyways.
Can you give us more information? What’s the make/model of headset? How are you connecting the headset? Can you grab the following info for me? sudo dmesg | grep ALC295. If it comes back empty, then the chipset has changed and it’s probably not the same issue. Also, grab cat /sys/class/dmi/id/product_{name,sku,version}? Also forgot what kernel you are running uname -r.
What’s the make/model of headset?
This is a standard set of OEM Apple 3.5mm headphones with a microphone.
How are you connecting the headset?
I’m plugging them directly into the on-board headphone jack on the side of the laptop.
Laptop details:
cat /sys/class/dmi/id/product_{name,sku,version}
Laptop 13 (AMD Ryzen AI 300 Series)
FRANVCCP09
A9
Grepping for ALC295 chipset in kernel log is empty:
sudo dmesg | grep ALC295
Kernel version:
uname -r
6.15.8
I don’t have that model laptop so I can’t help out much there. It sounds like a different chipset. There are two ways to approach this, I’d recommend either opening a support ticket with framework to see if they can help, or consider opening a new discussion thread. Perhaps somebody else could help out here, but with it being solved, it’s less likely to be reviewed.
I am encountering this issue as well, and I think it is the same issue that came up with the previous AMD boards - I just saw this article https://www.phoronix.com/news/Framework-13-AI-300-Headset so I am hoping that kernel update will fix it this time around as well.
I’m surprised a little 1 line patch got a shout out from Phoronix!
I tested the patch on my AI 7 350 before submitting it. It applies the same quirk discussed in this thread and it still works despite the different audio codec (ALC285 vs ALC295). I’m surprised to hear the dell-headset-multi modprobe flag didn’t fix the issue for you, @squat - that fix also worked for me. Just to confirm the kernel patch will actually take effect on the HX 370, could you check if get the same output from the command below? Specifically, Device 000b
❯ lspci -k -s c1:00.6
c1:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller
Subsystem: Framework Computer Inc. Device 000b
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
The patch just got pulled into the stable releases today (6.16.2, 6.15.11) so it should make it through to distro releases soon.
Mine looks identical:
lspci -k -s c1:00.6
c1:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller
Subsystem: Framework Computer Inc. Device 000b
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
hmm I might have biffed something when testing the kernel module options
First of all, thanks for submitting the patch!
I have been using mainline to get kernel updates, so I pulled 6.16.2 and tried it out. It doesn’t directly work for me, and I am also on a AI 7 350. However, I had also tried using hdajackretask in the past to try and get the mic working, but without success. With 6.16.2 in place, using hdajackretask now works. I tried enabling logging for ALSA at boot, and I see the following:
[ 3.024043] snd_hda_codec_realtek hdaudioC1D0: ALC285: picked fixup for PCI SSID f111:000b
Which seems to indicate the patch is getting picked up. But when I check the pin config after boot the mic pin 0x19 is back to the default state. As I said, I can then update it, and the mic works, but it doesn’t work at boot.