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?
3 Likes
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.
1 Like
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.
2 Likes
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.
1 Like
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?
1 Like
Yes but the impact is probably so small that it doesn’t really change the overall battery life.
Hi, Kinda late but I had the same problem on Arch Linux (EndeavourOS)
The fix is the same. When I switched state to 1 the buzzing immediately started.
I’m on Arch Linux. The solution works, but only temporarily - when I restart OR if i plug out or plug in the charger after running that command - the setting resets and I get the buzzing. Anyone know a permanent solution to the problem? I even agree to a hacky solution like a service that runs this command each time on restart and on change of power source.
The awful idea I had was just write a while loop to check the file to see if it ever changes from 0, then run the command to set it to 0 again. Maybe put a sleep in there so you aren’t just doing that all the time. Create a systemd unit file to run that script and enable it. Not trying to promote my silly wiki doc, but something like the following: Power Management - taim/my-setup - Codeberg.org. I’m not seeing that problem, so I can’t test it.
With the help of ChatGPT I (or chatgpt) came up with a somewhat more elegant solution (still hacky):
Create service
sudo nano /etc/systemd/system/set-snd_hda_intel-power_save.service
with the following content
[Unit]
Description=Set snd_hda_intel power_save parameter to 0
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo 0 > /sys/module/snd_hda_intel/parameters/power_save'
[Install]
WantedBy=multi-user.target
enable and start service
sudo systemctl enable set-snd_hda_intel-power_save.service
sudo systemctl start set-snd_hda_intel-power_save.service
Create udev rule
sudo nano /etc/udev/rules.d/99-power.rules
and paste following
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/usr/bin/systemctl start set-snd_hda_intel-power_save.service"
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/usr/bin/systemctl start set-snd_hda_intel-power_save.service"
Reload and test rules
sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=power_supply
P.S.
Actual conversation with the almighty intelligence https://chatgpt.com/share/f2594693-1e2e-4f86-9e08-b3d76908da69. There is a suggestion for a script that sets everything up, I haven’t tried it though.
1 Like
You need to set is as kerner parameter. Preferably during the boot.
It wasn’t easy for me to find but in dracut there was a file that updates the kermer parameters with kernel updates. For vanilla system-d boot or for grub you have to find different methods. In systemd-boot there is a file in /efi(or boot) /loader/entries/
There you pick the file and edit it for the parameters. For me it was that amd gpu fix and this audio fix