TF2 has its sound cut out seemingly randomly

[djsigmann]

Your system information

• Steam Runtime Version: 3.0.20260316.216289 (sniper)

• Distribution (e.g. Ubuntu 18.04): 6.19.9-arch1-1

• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: https://gist.github.com/djsigmann/2e9bdb62311fa0c90f40d92a51c7de0d

• Have you checked for system updates?: Yes

• What compatibility tool are you using?: Steam Linux Runtime

• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?
  depot 1.0.20260218.209096
  LD_LIBRARY_PATH 1.0.20260218.209096 scout 1.0.20260218.209096
  scripts 0.20260218.0

• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?
  depot 2.0.20260316.216280
  pressure-vessel 0.20260313.0
  scripts 0.20260313.0
  soldier 2.0.20260316.216280 soldier 2.0.20260316.216280

• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?
  depot 3.0.20260316.216289
  pressure-vessel 0.20260313.0
  scripts 0.20260313.0
  sniper 3.0.20260316.216289

Please describe your issue in as much detail as possible:

The sound sometimes cuts out entirely when TF2 is running, this can happen a few seconds after starting up the game and loading into the main menu, half-an-hour later during a match, or even when the window is not in focus.
This state persists until the game is quit.

Pulseaudio (pipewire) still sees the game as an audio source during this time and nothing else seems to change there; there is simply no sound emitted by the application.

Steps for reproducing this issue:

1. Ensure that the steam linux runtime 3 (sniper) is updated to the latest current version (3.0.20260316.216289).
2. Launch TF2.
3. Wait until the game stops producing audio - it's easier to tell when this happens if you are in a match.

Workaround

Rolling back steam linux runtime 3 (sniper) to the previous version (3.0.20260218.209091) seems to fix this issue entirely.

[smcv]

This might be libsdl-org/SDL#14916. If it is, that's fixed in SDL 3.4.4, which will hopefully be in the next beta update.

[smcv]

@djsigmann, please try this with yesterday's SLR_sniper beta branch, which is labelled as version 3.0.20260415.224995 in SteamLinuxRuntime_sniper/VERSIONS.txt.

If my guess was correct and you were experiencing libsdl-org/SDL#14916, then the bug should have been present in the version you originally tried (3.0.20260316.216289, SDL 3.4.2) but should be fixed in the new beta (3.0.20260415.224995, SDL 3.4.4).

If that doesn't work, then more debugging will be needed. A good next step would be to see what happens if you set TF2's Launch Options to STEAM_COMPAT_RUNTIME_SDL2=classic %command% and continue to use the beta.

the latest current version (3.0.20260316.216289)

Note that this version was rolled back as a result of a different regression, so at the moment the "default" and "previous" versions are both 3.0.20260218.209091. As a result, if my guess about the root cause is correct, none of the branches available to you via Steam should have this issue: 3.0.20260218.209091 is too old, and 3.0.20260415.224995 is (hopefully!) too new.

It is possible to swap to any past or present version for testing purposes by moving steamapps/common/SteamLinuxRuntime_sniper out of the way, and replacing it with the result of unpacking the SteamLinuxRuntime_sniper.tar.xz from a version-numbered subdirectory of https://repo.steampowered.com/steamrt3/images/.

3.0.20260218.209091 would not show libsdl-org/SDL#14916 in TF2, because it uses "classic" SDL2 for SDL2-based games like TF2, and that version doesn't provide native Pipewire audio at all, only a PulseAudio backend that works via Pipewire's PulseAudio compatibility layer pipewire-pulse. Newer versions 3.0.20260316.216289 and up use sdl2-compat for SDL2-based games, which means that if there's a bug like libsdl-org/SDL#14916 in SDL3, then that bug can affect SDL2 games as well.

[djsigmann]

I can confirm using version 3.0.20260415.224995 does seem to fix the sound issue on my machine.

However, even though this is unrelated to the original issue, I thought I'd mention it anyway:
Using this version of the steam linux runtime (sniper) seems to result in severe and prolonged framerate issues. When graphed over time, the frametime seems to bounce very frequently as shown in the screenshot below:

I'm not sure if this is expected behaviour when switching runtimes (similarly to how CS2 needs to recompile shaders for each map every now and then), or not, but it seems to persist across game restarts, and does not appear to occur when loading a map offline using the map command, only when connected to a server (tested both valve casual and community servers).

Please let me know if this should be a separate issue.

[smcv]

Please let me know if this should be a separate issue.

Yes please, it's better if we have one issue per problem - otherwise we get issues that can never be closed.

Perhaps the most likely root cause is the move from "classic" SDL 2 to sdl2-compat. It would be useful if you could test this theory by comparing:

1. updated beta 3.0.20260415.224995, launch options STEAM_COMPAT_RUNTIME_SDL2=classic %command%
2. updated beta 3.0.20260415.224995, launch options STEAM_COMPAT_RUNTIME_SDL2=compat %command%
3. default version 3.0.20260218.209091, launch options STEAM_COMPAT_RUNTIME_SDL2=classic %command%
4. default version 3.0.20260218.209091, launch options STEAM_COMPAT_RUNTIME_SDL2=compat %command% (the audio bug reported here might come back, please ignore that)

If you are using other custom launch options, add environment variables before the %command% or command-line options after the %command%, for example MANGOHUD=1 STEAM_COMPAT_RUNTIME_SDL2=classic %command% -vulkan.

If the frame-time issue is a regression in sdl2-compat, then I would expect it to appear in (2.) and (4.) but not in (1.) and (3.). If that happens, the SDL team will want to know about it.

Or, if it's a regression in some other part of SLR, I'd expect it to appear in (1.) and (2.) but not in (3.) and (4.).

Please comment on your new issue report with the results.

[djsigmann]

@smcv Fair enough, I'll create a new issue after testing what you mentioned.

As far as I can tell, I am unable to reproduce the sound issue with 3.0.20260415.224995, and I believe this issue may be closed once the beta release is pushed to latest.

[smcv]

As far as I can tell, I am unable to reproduce the sound issue with 3.0.20260415.224995, and I believe this issue may be closed once the beta release is pushed to latest.

I might have have misinterpreted what you originally said? I thought you were reporting that 3.0.20260218.209091 worked well, but 3.0.20260415.224995 had the performance problem you described (a regression). If 3.0.20260218.209091 had the performance problem but 3.0.20260415.224995 works well, then that's much more positive.

[djsigmann]

No, no, you did interpret me correctly.
3.0.20260218.209091 (4) / 3.0.20260316.216289 has the sound issue.
3.0.20260415.224995 has the weird perf issues.

That being said, I'm currently unable to repro the perf issue on either SLR version with either envvar...I think it may just have been a fluke, guess it's a good thing I didn't start an entire new issue yet.

I'm still able to repro the sound issue on 3.0.20260218.209091 with STEAM_COMPAT_RUNTIME_SDL2=compat as expected.

EDIT: I'm tearing my hair out with these version strings