I’ve been troubleshooting a collection of strange problems on Fedora 44 for several months and have mostly run out of ideas. I apologies ahead of time for the wall of text but I figure too much info is better then too little for something like this, also I’m a new Linux user so forgive me any stupid mistakes you see that I made.
I originally treated them as separate issues, particularly the audio problem, but I’m increasingly wondering whether some of them share a cause involving suspend/resume, NVIDIA, ACPI, power management, or hardware state not being restored correctly.
I’m hoping someone more familiar with Fedora/Linux on ASUS + NVIDIA gaming laptops recognizes the pattern.
Hardware / system
- ASUS ROG Strix SCAR 16 G634JYR
- Intel Core i9-14900HX
- NVIDIA GeForce RTX 4090 Laptop GPU
- 64 GB RAM
- Fedora Workstation 44
- GNOME / Wayland
- NVIDIA proprietary driver from RPM Fusion
- Hybrid graphics
- Kernel during much of the troubleshooting: 7.1.3-201.fc44.x86_64
- NVIDIA driver currently/at one point during testing: 610.43.03
- PipeWire audio
- TuneD/tuned-ppd for power profiles
- supergfxctl / asusctl installed
Important Windows comparison
This laptop previously ran Windows 11 as its primary OS for months/years before I switched it to Fedora. I regularly gamed on it and put the CPU/GPU under sustained heavy loads during that time, and I never encountered the audio crackling or suspend/resume instability described below.
The hardware itself has not materially changed since switching operating systems.
I realize that doesn’t completely rule out a coincidental hardware failure, but the problems appeared after moving to Linux/Fedora and weren’t present during a long period of comparable use under Windows. That’s one reason I’m more suspicious of a Linux driver/kernel/firmware/power-management interaction than failing speakers or other physical hardware.
Problem #1: Audio begins crackling after sustained load
When the laptop is cool/freshly started, audio sounds completely normal. After sustained gaming/heavy load, it begins crackling/popping.
Once the crackling starts, it isn’t necessarily limited to the game. I’ve reproduced it with local MP4 playback as well. Browser/YouTube playback has sometimes behaved differently, which initially made me suspect Proton or an individual game, but the problem clearly isn’t confined to one application.
Letting the laptop cool down seems to make the problem disappear again.
I’ve managed to get some reasonably repeatable temperature observations:
Clean audio: CPU package ~63°C, RAM ~51-54°C Crackling: CPU package ~92-94°C, CPU cores mostly mid/high 80s to low 90s, RAM ~58-74°C depending on the test
The fans are responding normally and ramp substantially under load: roughly ~6200 RPM CPU, ~5800 RPM GPU and ~7300-7400 RPM middle fan.
I’m not assuming that temperature itself is physically breaking the audio. Heat may simply be a proxy for sustained CPU/GPU load, throttling, power-state changes, interrupt latency, etc. What I can say is that “cold/lightly loaded = clean” and “sustained heavy use/hot = crackling” has been reasonably repeatable.
This same laptop handled sustained gaming loads under Windows without developing the crackling.
Problem #2: Suspend/resume seems to make the entire system less stable
This is the part that makes me wonder whether I’m dealing with a broader power-management/driver problem rather than completely unrelated bugs.
The laptop doesn’t reliably suspend. Sometimes I select Suspend or close the lid for the night and discover the next day that it apparently never actually went to sleep, eventually draining the battery.
More interestingly, the computer can be behaving completely normally before suspend and then have various things stop working or behave incorrectly after waking.
After a problematic suspend/resume cycle I’ve seen combinations of:
- Steam games refusing to launch
- Steam appearing to start a game, waiting for a while, then silently returning to the Play button
- Games that do launch running at ~3 FPS
- Chrome and other desktop applications becoming extremely sluggish
- Subsequent suspend attempts failing
- Display brightness controls sometimes stopping working entirely, leaving the display stuck at maximum brightness
- Rebooting generally restoring normal behavior
The brightness issue is comparatively minor, but I’m mentioning it because it specifically appears after suspend/resume and seems like another piece of hardware/display state that occasionally isn’t being restored correctly (well, that and it’s really annoying).
The suspend problem isn’t perfectly reproducible. Sometimes it works normally. But suspend/resume seems to substantially increase the likelihood of the computer entering this “broken” state.
I’ve also reproduced a particularly severe suspend failure where instead of returning to GNOME normally, the machine dumped me to kernel messages and became effectively unusable.
Among the messages I’ve caught during these failures were:
- systemd-sleep[…] exited with irqs disabled
- along with NVIDIA-related errors/messages including:
- nvAssertFailedNoLog: Assertion failed
- RmHandleNotifierEvent: Failed to handle ACPI D-Notifier event
- and output involving nvidia_modeset / nvkms.
This obviously makes me suspicious of NVIDIA/ACPI/suspend interaction, although I don’t know whether that has anything to do with the audio problem.
One NVIDIA problem we DID identify and fix
At one point after a normal Fedora update, Project Wingman suddenly ran at approximately 3 FPS and:
nvidia-smi
returned:
Failed to initialize NVML: Driver/library version mismatch
The installed NVIDIA userspace/packages were 610.43.03, while the running kernel still had the older 595.80 NVIDIA module loaded.
Running:
sudo akmods --force
and rebooting fixed that particular problem. nvidia-smi then reported 610.43.03 correctly and gaming performance immediately returned to normal.
I don’t think that mismatch explains the long-running audio/suspend problems because they existed outside that particular incident, but I’m mentioning it because NVIDIA/kernel state has demonstrably caused severe performance problems on this machine before.
Things I’ve already investigated/tried
- Confirmed that the crackling isn’t limited to one game.
- Confirmed that it can affect local media playback.
- Compared temperatures while audio is clean vs crackling.
- Allowed the machine to cool and reproduced clean → sustained gaming/load → crackling.
- Checked fan behavior.
- Investigated Fedora Performance/Balanced power-profile behavior.
- Found an older Fedora report where replacing TLP/power-profiles-daemon with TuneD fixed load-dependent audio crackling.
- My Fedora 44 installation already uses TuneD/tuned-ppd.
- power-profiles-daemon and TLP aren’t installed.
- Changing/confirming TuneD profiles did not solve the crackling.
- Installed asusctl and supergfxctl to get proper ASUS/ROG hardware and hybrid-graphics control.
- supergfxctl -g reports Hybrid.
- Inspected NVIDIA module parameters. These have included PreserveVideoMemoryAllocations: 2 and UseKernelSuspendNotifiers: 1.
- Rebuilt the NVIDIA kernel module after catching the separate driver/library mismatch described above.
Things I’ve considered but deliberately haven’t started changing yet:
Replacing pipewire-pulseaudio with actual PulseAudio as a controlled A/B test Using rtla to investigate scheduling/interrupt latency More invasive NVIDIA suspend/power-management configuration changes
I’m deliberately trying not to shotgun random configuration changes at the machine because I’d rather isolate the cause than accidentally make the problem disappear without learning what fixed it.
Next test I was planning: clean Fedora Live USB
The next experiment I was planning is to boot Fedora 44 from a completely clean Live USB, play audio, and use something like stress-ng to put the machine under sustained load and bring it into roughly the same thermal range.
My reasoning is:
If stock Fedora 44 Live also begins crackling under sustained load: that would strongly suggest the problem isn’t caused by months of configuration changes to my installed Fedora system.
If Fedora Live remains clean at comparable load/temperature: that would point toward something different about my installed system.
I’m also interested in seeing how suspend/resume behaves from the clean environment.
I haven’t done this test yet mostly because after several months of troubleshooting this plus the NVIDIA/suspend problems, I’ve gotten somewhat burned out on testing and wanted some fresh eyes before continuing.
Current theories, not conclusions
At this point I’m considering:
- PipeWire/WirePlumber buffering or scheduling breaking down under sustained load
- Kernel/ALSA interrupt or scheduling latency
- ASUS/Intel power-management behavior under sustained load
- NVIDIA Hybrid graphics/power management
- NVIDIA state not being restored correctly after suspend
- ASUS ACPI/firmware interaction with Linux
- Some combination of the above
- Actual thermal sensitivity/hardware failure, although I currently consider this less likely because this machine previously handled sustained gaming loads under Windows 11 without these problems
One thing I’m particularly unsure about is whether I’m actually looking at multiple unrelated bugs.
The audio problem doesn’t have an established relationship with suspend/resume. Its strongest correlation is sustained load/temperature, so I don’t want to imply otherwise.
However, seeing a normally functioning computer sometimes come out of suspend with games running at ~3 FPS, desktop applications crawling, brightness control broken, further suspend attempts failing, and NVIDIA/ACPI errors makes me wonder whether there’s a lower-level power/state-management problem manifesting in several different ways.
If anyone recognizes this pattern, I’d particularly appreciate suggestions for one or two high-information diagnostic tests rather than a large list of configuration tweaks.
I’m happy to provide inxi -Fxxxz, journalctl, wpctl, PipeWire information, lspci, nvidia-smi, rtla, suspend logs, etc. if there’s something specific worth looking at.
I’m planning to eventually file a proper Fedora/Red Hat bug report, but before doing that I figured it was worth asking here in case someone recognizes this as a known ASUS/NVIDIA/Fedora problem.
Help me internet, you’re my only hope. Also, I offer free pictures of my cats being adorable as a bribe to anyone who can solve this, or at least provide any material assistance since I’ve been fighting this for months now and am on my last threads of sanity.