After upgrading my Framework 13 from 11th Gen Intel to the new AMD board, I am getting a loud buzzing sound through the headphone jack when audio is not playing.
If I play audio the buzz goes away and comes back 1-3 seconds after the audio playback stops.
I’m running Fedora 39 Beta 1.1. I’ve observed this behavior on both KDE and GNOME desktop environments.
Mine has been more of a popping when audio is about to play and when the audio is finished playing.
Correct. I’m on BIOS 3.03.
I should also note I’m on a fresh install of Fedora 39 Beta 1.1 on the AMD hardware.
Can you reproduce with powersaving for the audio card disabled. I know it was an issue with the audio card on the 11th board so maybe the 13th board as the same “problem/limitation” with the card it was on.
Same. Latest kernel and updates from F39 updates.
Whoa, @Danny_Colin the solution in this post on the original 11th gen audio issues worked! I was a bit surprised as it appeared to be Intel specific but maybe the audio breakout board is Intel based in some way?
echo 0 | sudo tee /sys/module/snd_hda_intel/parameters/power_save
I’ll apply the snd_hda_intel.power_save=0 kernel boot parameter to resolve on this OS installation.
Odd that it resurfaced though. I think I remember having this issue back when I originally got the 11th gen laptop but I definitely haven’t experienced it for quite a while until I installed the new AMD board. @Matt_Hartley is this something you’re already aware of and might we be able to get the fix available generally for the new board?
Well, if both boards are using the same or similar audio chipset, they’d have the same issue. AFAIK, this is an hardware limitation on the 11th gen so it can’t be fixed. I guess we’ll need to wait for Matt confirmation to know if that’s also the case on the AMD board.
Been slammed, sorry for the delay. Few things.
It’s a Realtek and it does support power save after looking into the modinfo for this card. In theory, your command would possibly stop power save.
I tested this on Ubuntu 22.04.3 with OEM C kernel (6.1.0.1025) and audio played fine and had no buzzing. Tested with and without FW provided AC power brick attached.
Does the laptop do this when detached from power and also have you tried this in another area to see if it is interference elsewhere? I want to eliminate EMI from the equation.
Have you tested another set of headphones or other 3.5 mm device?
Lastly, if all above fails - try re-seating your board - could be mounted in such a way as to create the issue. Reconnect your audio cable after disconnecting it.
I’m on AMD with F39, latest updates-testing
The echo 0 | sudo tee /sys/module/snd_hda_intel/parameters/power_save trick worked for me. I notice popping sounds when audio is about to begin and shortly after it ends. It does this on and off power. I’ve heard this with more than just a single set of headphones, I do notice it more on headsets.
Interesting! I’ll make a mental note that some users may need to zero in on power save on these Realtek audio configs.
I’m working a theory. I added the dell-headset-multi work-around until a kernel patch lands. I’m wondering if my symptoms are specific to that. I’ll try to remember to check that after work.
The fix worked for me as well, and I had the same problem. Buzzing when audio is not playing. I’m on a framework 13 AMD.
Sounds like this has worked for multiple people, including @keawade - marking this solved.
Will add this into the doc. Can I get a list of distros and their release versions from everyone before I do?
Confirmed for Fedora 39, anyone for Ubuntu LTS?
Yes, Ubuntu LTS here
I finally got around to testing. Using a fresh copy of F39 updated to the lastest available today, using my headset without the dell-multi-headset work-around, I still get popping sounds when starting audio and a while after the audio has stopped. I stand by the fix I mentioned above for my specific problem.
Same issue here, Framework 13 AMD, Fedora 39, kernel 6.7.6
I applied the workaround while the buzzing was going on and it immediately stopped.
While the issue is marked as resolved, isn’t this workaround ultimately affecting battery life?
Yes but the impact is probably so small that it doesn’t really change the overall battery life.