Internal audio controller on Framework 13 AMD Ryzen HX370 no longer recognised

[ported-pw]

Describe the bug

After updating to gts-20250720 from gts-20250706, the internal audio controller and thus the 3.5mm headphone jack on the Framework 13 HX370 no longer works.

The card does not show up under pactl, the issue is already earlier:

bash-5.2# lspci -k | grep -A 3 "c1:00.6"
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
c1:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller
    Subsystem: Framework Computer Inc. Device 000b
    Kernel modules: snd_hda_intel
c2:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo PCIe Dummy Function
bash-5.2# ls -la /sys/bus/pci/devices/0000:c1:00.6/driver
ls: cannot access '/sys/bus/pci/devices/0000:c1:00.6/driver': No such file or directory
bash-5.2# echo "0000:c1:00.6" | sudo tee /sys/bus/pci/drivers/snd_hda_intel/bind
0000:c1:00.6
tee: /sys/bus/pci/drivers/snd_hda_intel/bind: Device or resource busy
bash-5.2#

The driver does not get loaded, and by default the device is disabled and has an invalid IRQ:

❯ sudo lspci -s c1:00.6 -v
c1:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller
    Subsystem: Framework Computer Inc. Device 000b
    Flags: fast devsel, IRQ 255, IOMMU group 29
    Memory at b04c0000 (32-bit, non-prefetchable) [disabled] [size=32K]
    Capabilities: [48] Vendor Specific Information: Len=08 <?>
    Capabilities: [50] Power Management version 3
    Capabilities: [64] Express Endpoint, IntMsgNum 0
    Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
    Capabilities: [2a0] Access Control Services
    Kernel modules: snd_hda_intel


~ 
❯ echo 1 | sudo tee /sys/bus/pci/devices/0000:c1:00.6/enable
1

~ 
❯ sudo lspci -s c1:00.6 -v
c1:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller
    Subsystem: Framework Computer Inc. Device 000b
    Flags: fast devsel, IRQ 26, IOMMU group 29
    Memory at b04c0000 (32-bit, non-prefetchable) [size=32K]
    Capabilities: [48] Vendor Specific Information: Len=08 <?>
    Capabilities: [50] Power Management version 3
    Capabilities: [64] Express Endpoint, IntMsgNum 0
    Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
    Capabilities: [2a0] Access Control Services
    Kernel modules: snd_hda_intel

Rolling back to 20250706 fixed it.

What did you expect to happen?

For the driver to be bound so Pipewire can recognise the device.

Output of bootc status

Output of groups

Extra information or context

No response

[dosubot]

Hi @ported-pw! I'm Dosu and I’m helping the bluefin team.

This issue appears to be a regression introduced in gts-20250720, as rolling back to gts-20250706 restores audio functionality. No direct configuration or kernel argument changes in Bluefin itself were found that would block the audio device, so the most likely cause is a change in the underlying kernel, drivers, or a related package included in the new release.

A few things to check and try:

• Make sure your BIOS setting for "Linux Audio Compatibility" is set to "Linux"—this is required for audio to work on Framework laptops. You can find step-by-step instructions in the official Bluefin Framework documentation.
• Ensure your BIOS/UEFI firmware is fully up to date, as outdated firmware can cause hardware compatibility issues (source).
• Some users have reported that after certain Bluefin updates, minor manual tuning (like adjusting sample rate or target selection) was needed for optimal audio performance, especially after firmware or PipeWire integration changes. See the discussion on audio device issues after Bluefin updates.
• If the device is still not recognized, collect dmesg and journalctl logs after boot for further diagnosis.

If none of these steps resolve the issue, the safest workaround is to remain on the last working release (gts-20250706) and monitor for updates or fixes in future releases.

For more details, see the Bluefin Framework documentation.

Tip: You can use tldr lspci to quickly review how to use the lspci tool for troubleshooting hardware devices.

Full documentation: https://docs.projectbluefin.io

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ported-pw]

There is no such option ("Linux audio compatibility") in the Framework 13 HX370 BIOS.

[dosubot]

You're correct—the Framework 13 HX370 BIOS does not have a "Linux audio compatibility" option, so that advice doesn't apply here (source). The regression you’re seeing after the gts-20250720 update is most likely due to an upstream kernel or driver change, not a Bluefin configuration change. The Bluefin scripts for Framework audio support (like the 3.5mm jack fix) have not changed between these releases, and no model-specific kernel arguments are documented for this device.

The best workaround for now is to stay on the last working release (gts-20250706) and keep an eye out for kernel or akmod updates that may resolve the issue. If you want to help diagnose or report the regression upstream, collecting detailed dmesg and journalctl logs after boot on the broken release will be useful.

Full documentation: https://docs.projectbluefin.io

Tip: Use tldr dmesg or tldr journalctl for quick command usage help.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[castrojo]

The kernel hasn't changed in these 2 weeks so it's probably something else causing the regression. Let me ask around.

[kreed]

I tried reproducing this on my Framework 13 Ryzen AI 350 but no luck. Both speakers and the 3.5 mm jack worked fine for playing audio on gts-20250720

[ported-pw]

@kreed it is still broken for me on gts-41.20250810.
@castrojo Please let me know if there's any further information or debugging I can provide.

[ported-pw]

Found the initialization sequence in dmesg:

bash-5.2# dmesg | grep c1:00.6
[    0.370200] pci 0000:c1:00.6: [1022:15e3] type 00 class 0x040300 PCIe Endpoint
[    0.370221] pci 0000:c1:00.6: BAR 0 [mem 0xb04c0000-0xb04c7fff]
[    0.370228] pci 0000:c1:00.6: enabling Extended Tags
[    0.370260] pci 0000:c1:00.6: PME# supported from D0 D3hot D3cold
[    0.413795] pci 0000:c1:00.6: Adding to iommu group 29
[   26.819438] snd_hda_intel 0000:c1:00.6: cannot find the slot for index 0 (range 0-1), error: -16
[   26.819449] snd_hda_intel 0000:c1:00.6: Error creating card!
[   26.819452] snd_hda_intel 0000:c1:00.6: probe with driver snd_hda_intel failed with error -16

[ported-pw]

Claude.ai figured it out for me. Not sure if the technical analysis is perfectly sound but it did get the conclusion right:
https://claude.ai/public/artifacts/6b26a053-2393-4e5c-9adc-833f7b4b334b

So the issue seems to be a firmware update plus the existing ALSA module config that currently is this:

# /etc/modprobe.d/alsa.conf
options snd-hda-intel index=1,0 model=auto,dell-headset-multi

changing it to this fixed the issue for me:

options snd-hda-intel model=auto,dell-headset-multi

I don't know enough to know if this is a good solution, just sharing my current solution to get back to work^^

[dosubot]

Hi, @ported-pw. I'm Dosu, and I'm helping the bluefin team manage their backlog and am marking this issue as stale.

Issue Summary:

• Internal audio on Framework 13 AMD Ryzen HX370 stopped working after updating to gts-20250720 due to snd_hda_intel driver failing with an invalid IRQ.
• The regression was suspected to be from upstream kernel or driver changes; workaround was to stay on gts-20250706.
• Maintainers noted no kernel changes and could not reproduce the issue on similar hardware.
• You discovered that removing the "index=1,0" option from the ALSA module config resolved the issue.
• This indicates a firmware update combined with the existing ALSA config caused the failure.

Next Steps:

• Please confirm if this issue remains relevant with the latest Bluefin updates.
• If it is still a problem, feel free to comment to keep the discussion open; otherwise, I will close this issue automatically in 14 days.

Thanks for your understanding and contribution!

For more details, see the official documentation at https://docs.projectbluefin.io