Steam Game Recording choppy with audio delay on kernel 7.0.10-1-cachyos

Yxoko · May 25, 2026, 5:20pm

When watching a Steam Game Recording replay via the in-game overlay on kernel 7.0.10-1-cachyos, the playback is very choppy and has an audio delay. The issue affects all games (both native Linux and Proton). Downgrading to the LTS kernel (6.18.33-1-cachyos) completely resolves both issues.

I recorded with a GPU graph and we can see that the moment I open the Steam Overlay, there’s a usage spike that goes back to normal when closed. While watching a replay, the usage drops significantly, then goes back to a higher level when I stop watching, and returns to normal the moment I close the overlay. In the recording there are also frames where my wallpaper is briefly visible. The audio delay is not present in this specific recording but I have other clips where it is, which seems to appear when playing for a long time.

Here’s the video.

After booting to the LTS kernel, opening the Steam Overlay still causes a brief usage spike, but watching a replay works perfectly fine.

Here’s the video of the workaround.

By the way, in my videos, I wait before opening the Steam Overlay to let the map and shaders finish preloading, which is visible as GPU usage drops in the graph.

System information:

Kernel (broken): 7.0.10-1-cachyos
Kernel (working): 6.18.33-1-cachyos-lts
CPU: AMD Ryzen 7 5800X
GPU: AMD RX 7800 XT
Desktop: KDE Plasma 6.6.5, Wayland
Steam version: 1779479049 (Beta, May 22 2026)

Steps to reproduce:

Boot into kernel 7.0.10-1-cachyos
Launch any game via Steam
Open the Steam overlay and watch a clip via Steam Game Recording

Expected behavior: Overlay and replay playback render smoothly

Actual behavior: Replay playback is choppy with audio delay. GPU usage briefly spikes when the overlay opens, then drops significantly during replay playback.

Confirmed workaround: Booting into 6.18.33-1-cachyos-lts fully resolves the choppiness, though the brief GPU spike on overlay open persists.

Things already tried that did not help on 7.0.10:

Disabling GPU accelerated rendering in Steam web views
Switching Steam from beta to stable branch

eskay993 · May 26, 2026, 11:48am

Same issue for with Steam Overlay poor performance (not just with recording). It’s as soon as you open the overlay, it lags horribly and becomes unusable.

I’ve narrowed it down to kernel 6.19 where this started to happen. 6.18 and 6.18 LTS work fine for me too. 6.19 has the severe lag.

Here’s an issue about it over on Valve’s repo:

github.com/valvesoftware/steam-for-linux

very poor performance using in-game overlay and virtual menus

opened 10:29PM - 14 May 26 UTC

richardegoldstein7-spec

overlay Distro Family: Arch

#### Your system information * Steam client version (build number or date): Sta…ble Client 1778281814 * Distribution (e.g. Ubuntu): 7.0.6-arch1-1 with kde plasma 6.6.5 * Opted into Steam client beta?: No * Have you checked for system updates?: Yes * GPU: AMD 9070xt, CPU AMD Ryzen 5 7600x, 32 GB ram * monitors used while testing: 1440p 75hz multi monitor, 4k 60hz single monitor #### Please describe your issue in as much detail as possible: I am having a continuous and mysterious bug specifically associated with the steam overlay which causes its performance in-game to be simply atrocious. This occurs both in and out of BPM, and is especially bad whenever invoking on-screen virtual menus: pulling up the menu or moving through it's options will cause horrible stuttering in game. The steam overlay itself is very laggy, especially in the controller layout menu. I have tried many different possible fixes, including: -using gamescope -using the arch linux zen kernel -adjusting number of monitors and refresh rates on those monitors -env STEAM_RUNTIME=1 steam -no-cef-sandbox -cef-force-glx -disabling and enabling hardware acceleration in the interface settings -updating all linux systems and drivers via sudo pacman -Syu -KWIN_DRM_NO_DIRECT_SCANOUT=1 and some other things as well This is not specifically with using the new steam controller, I have also tested with a dualshock 4 and the same stuttering persists when invoking an onscreen radial menu. This issue does not persist on the steam deck. #### Steps for reproducing this issue: 1. open the steam overlay while in game (performance will already be poor) 2. create and use any sort of virtual menu (radial, touch, all of these will reproduce the same stuttering when being invoked/used)

Hopefully there is a temp fix / workaround on the cachyos side we can do (besides using 6.18 LTS)

Yxoko · May 26, 2026, 6:58pm

My Steam Overlay used to be choppy too but for some reason, it fixed itself? Like dragging windows in the overlay was choppy as well as my cursor, but after letting the game run for a bit longer, the overlay was no longer choppy.

Zen · May 27, 2026, 5:31am

I really hope there’s a solution to this soon. It’s a shame especially for a gaming focused distro.

Shadow_Death · May 27, 2026, 4:44pm

Same issues here with similar hardware.

I switched to the LTS Kernel and the issue went away.

Beowulf1220 · June 9, 2026, 8:21pm

Same here, can confirm this looks like a kernel regression.

Setup: RX 9070 XT (RDNA4 / gfx1201), Ryzen 7 5700X, Arch + KDE Plasma 6 (Wayland),
Mesa 26.1.2, native Steam.

The Steam Game Recording in-overlay player (“Show Recording”) stutters/freezes
constantly while the game in the background runs perfectly fine. The recording itself
is only H.264 1080p60 ~12 Mbps and plays back perfectly smooth in mpv/VLC and when
exported — it’s ONLY the in-overlay CEF player that’s choppy.

I tested the exact same recording across all my installed kernels:

✅ linux-lts 6.18.35     -> perfectly smooth 
❌ linux 7.0.11          -> choppy 
❌ linux-zen 7.0.11      -> choppy 
❌ linux-cachyos 7.0.11  -> choppy

So it’s not a CachyOS-specific patch, Mesa, or a Steam setting — it also reproduces on
plain mainline 7.0.11, and only the 6.18 LTS is clean. Looks like an amdgpu/kernel
regression introduced somewhere after 6.18. VA-API encode/decode is otherwise fine
(vainfo OK, exports fine).

Booting linux-lts is a working workaround for now.