Tried another run with a native d3dcompiler_47/43 per @kisak-valve's advice. Same result, without the HLSL compiler errors.

It should be noted this happens on both wined3d and dxvk, I experienced the same issue. Once you go into game then back out into the character select it renders fine.

Do you see any intro sequences when starting the game before reaching the menu?

For some strange reason, the game decides to paint a completely black full-screen quad over the menu background, which doesn't happen on Windows. The background itself is 3D graphics rather than a video.

All I saw was a blank screen, some legal text at the bottom, followed by the aforementioned menus, all blank screens. I suppose I'm looking at the black quad; why that's showing up i have no idea :/

after installing Media Foundation ( <Link removed by moderator> ) using DXVK i can see everything correctly (but i had totally black screen before)

Yes, the game is working fine:
<Link removed by moderator>

After yesterday update the game crashes immediately after start:
steam-617290.log
System Information

UPD: The game is working with GloriousEggroll 5.6 GE2 Proton build
steam-617290.log

this game also has performance issue with proton. The game suddenly slows down to unplayable when changing settings or exit to main menu. Need to completely restart the game to restore performance.

I picked up this game for my partner and I to play together and my machine (current Arch) connects to multiplayer fine, but hers (Debian) hangs on connecting to matches. Has anyone else encountered this?

@grahampfau Looks like is a distribution problem. Debian seemed to have problem with games. Debian update is slower than other distributions. Debian is aimed to be stable and so not updated as often. Probably don't recommend Debian for games.

@grahampfau Did you ever find a solution? I'm currently experiencing the exact same issue but on Arch. The game plays perfectly offline but it hangs infinitely on "Connecting" when I try to join any games or when someone tries to join mine. I've tried various versions of Proton (including GE), different kernels, and connecting through a VPN.

Edit: From a Manjaro Live ISO with my Steam library and Proton mounted, I was able to connect online. So it might just be my particular installation.

Edit 2: Reinstalling Arch solved the problem. Still interested in what the actual problem was as people on Windows have reported solving it the same way....

Edit 3: The issue was having Docker running. It happened to me again and the only change I made to my system was configuring enabling Docker.

It won't launch on Proton 6.3 due to "DX11 feature level 10.0 is required to run the engine", but will run on experimental.

Proton 6.3-4 logfile: https://gist.github.com/Raklodder/b098254c55427f0da937b131ed01ff69
Full system specifications: https://gist.github.com/Raklodder/909cc2c3d4cab16add9b0661ed23ec83

@kisak-valve yes, thank you! Remnant: From the Ashes will run out of the box on proton-6.3-5-rc1.

It appears that having virtual network adapters set to up breaks multiplayer. That behavior is described in this Reddit post and shown in this YouTube video. The latter also presents the workaround to set all but one network adapter to down. Unfortunately, I can't use this workaround because my setup requires network bridges, so a proper fix (if possible) would be fantastic.

Here's a log file from starting the game with Proton 6.3-5, trying to connect to a friend's lobby (using crossplay with Epic, in case that's relevant), sitting in "Connecting..." for around 30 seconds, being brought back to the game's main menu screen without an error message and closing the game: steam-617290.log

It appears that having virtual network adapters set to up breaks multiplayer.

Aha, that explains why having the Docker daemon running breaks multiplayer. I believe a similar issue actually happens on Windows, as I remember someone there was experiencing the same symptoms and reinstalling their OS fixed it.

Compatibility Report

• Name of the game with compatibility issues: Remnant: From the Ashes
• Steam AppID of the game: 617290

System Information

• GPU: AMD Radeon RX 7900 XTX
• Video driver version: AMD Radeon RX 7900 XTX (gfx1100, LLVM 16.0.6, DRM 3.52, 6.4.3-1-default) 4.6 (Compatibility Profile) Mesa 23.1.3
• Kernel version: 6.4.3-1-default
• Link to full system information report as Gist:
• Proton version: 8.0-3

I confirm:

• [X] that I haven't found an existing compatibility report for this game.
• [X] that I have checked whether there are updates for my system available.

steam-617290.log

Reproduction

Without any parameter just set proton to version 8.0-3 and press play. The game will create a black window, that window will go fullscreen, after about 2-3 seconds it will crash to desktop showing this error report tool for unreal:

P.s.
I tested it also with Proton-GE and it achieves the same exact results. On the protondb page it was suggested that the game would run only once passing the parameter "-d3d11" to force the game to run with DirectX11. It unfortunately doesn't work either.

I have been playing this game from 2020, definitely before proton 6. had no problems running the game.
The errors and crashes because, must have been AMD driver problem. I have Nvidia and runs fine. I just checked Proton 8.0-3, still runs fine.

That's not something that would surprise me, AMD drivers are changing rapidly on Linux since the Steam Deck got released. I guess some older games like this one got left behind from some specific fixes, which is normal but still.. would like them fixed if possible.

Planning a full game run in co-op with a friend :)

@Plarpoon Have you tried an earlier version of Proton? I have a 6950XT on Arch with Mesa 23.1.3 and have been playing for a couple of years with various different Proton versions. I'm currently running GE 7-53 but I can test 8.0-3 when I get home later and see if I can replicate what you're seeing.

Thank you for telling me that it worked around that version, I have actually just tried it myself and yes, the game works perfectly well (for the very short test I did) with Proton 6.3-8.

I must say I was also using the launch parameter: "-d3d11"

Tomorrow with more time I should definitely do more testing, but that also unfortunately confirms that the game is dead with the most recent version of Proton. Undeniably so... at least with my hardware configuration. That's something that should be looked into.

@Plarpoon Glad that you found a configuration that works. I just finished my testing and found everything to be working well on both 8.0-3 and GE 8-9, so it does look like something more specific to your configuration. Unfortunately I don't have a current gen card to test more with.

If I can help you with any test you might want to do, providing logs or even screen sharing and spending some hours one day in fixing something let me know. I am up for everything, would be glad to give something back to the community!

Just to be clear, I'm not a wine/proton developer, I just really like this game and tinkering;)

If you want to spend the time debugging, see if you can find the latest Proton release that works. From there, it should be easier to nail down what might have changed.

I know you are not, but I like to believe that despite being less impactful since we are not actively contributing to the code we are still helping out by writing reports and issues here. I will definitely do some more tests as soon as I am back home, if you want to do some more specific testing I am up for it!

@Plarpoon Here are a few things to try to get to the bottom of this. Also - I noticed that both this game and DRG use UE4... it would be interesting if you happen to know if you have any UE4 games that do work with Proton 8?

1. Could you try Remnant: From the Ashes with Proton 7.0-6 to see if it regressed between those versions or if the breakage for this one is between 6.3-8 and 7.0-6 instead?
2. Could you describe your audio configuration? The easiest way to do this is likely to just take screenshots of the following tabs on pavucontrol: output devices, input devices, and configuration.
3. What sound server is being used (pipewire, pulse audio, etc)? Please give the exact version # :)
4. It could be interesting to try messing with the audio configuration in pavucontrol a bit to see if the behavior with the game changes. If you are able to fix the game by doing this, it would be great if you could tell us exactly what you changed so we can look into the issue :)
5. Assuming Step 4 did not fix your issue, could you provide a log with PROTON_LOG=+alsa,+mmdevapi,+pulse,+relay %command%?

@alasky17 Here is everything as asked, unfortunately I will have to leave in 2 days for a max of 8 days, there is a project I have to conclude in Ireland and my desktop computer will remain in Italy. I can do any other experiment you might need tonight and the whole of tomorrow but then I will have to take a quick pause, hope that is fine!

Good news: issue has been identified, it is an error with the audio devices. tl;dr at point number 4.
Bad news: I made a wall of text, sorry :(

1. The game works really well under Proton 7.0-6, the regression must have happened somewhere between that version and 8.0-3. I have tried both these experiments without the parameter "-d3d11" that was previously recommended (the parameter window is now completely empty).

2. I don't normally use pavucontrol so I am terribly sorry for the spam of pictures, as you will notice I have a lot of audio related devices as I have equipped my computer with an Asus Xonar DX (here is the link to its datasheet). I don't really have a strong reason for it, I just prefer the audio quality given by an actual audio card to the one of the embedded audio on the motherboard. I also own a Blue Yeti USB microphone (specifications here) and as output the Razer Tiamat 7.1 (specifications here) for which I use all of the available jacks connected to the audio card and a USB cable to power up the headset.

(I am terribly sorry I couldn't embed the pictures into a spoiler tab, they just break when doing so)

1. pactl info result including the server name and version:

Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 5091
Tile Size: 65472
User Name: plarpoon
Host Name: daisy
Server Name: PulseAudio (on PipeWire 0.3.72)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_08_04.0.analog-surround-71
Default Source: alsa_input.usb-Blue_Microphones_Yeti_Stereo_Microphone_REV8-00.analog-stereo
Cookie: 200b:37a4

1. I messed with the audio configuration tab in pavucontrol and discovered that as long as my Trust QHD Webcam or my Game Capture HD60S+ are enabled with any settings (I tried them all, they all give issues) the game will create the black window, crash and then show the Unreal error box as described before. If that is instead set to Off there will be no issues in the loading even with Proton 8.

2. I know you said to do this only if point 4 was not successful but you can always ignore it if not needed and it might provide extra feedback for something I forgot to specify in my report. Also I hope it's fine that I compressed the archive as in full size is above 1,1GB in size and I have lots of issues uploading it. I have done this test setting "Trust QHD Webcam" to "Analog Stereo Input". Here is the log, mediafire because even while compressed the file is still almost 32MB in size...
   https://www.mediafire.com/file/puh8s7hmn5w171a/steam-617290.zip/file

I messed with the audio configuration tab in pavucontrol and discovered that as long as my Trust QHD Webcam or my Game Capture HD60S+ are enabled with any settings (I tried them all, they all give issues) the game will create the black window, crash and then show the Unreal error box as described before. If that is instead set to Off there will be no issues in the loading even with Proton 8.

That's an interesting finding. I have HD60S+ around so I can give it a shot.

I'm a bit surprised it's an input device, but that may explain why you hit the issue with Remnant and DRG only, both have built-in voice chat. I wonder if they use the same UE4 plugin.

I have done this test setting "Trust QHD Webcam" to "Analog Stereo Input". Here is the log, mediafire because even while compressed the file is still almost 32MB in size...

Sadly the game doesn't progress to the point where audio devices are used. +relay probably messes things up.

Can you try to repro the issue with only a single output that's not 7.1 and only HD60S+ input being enabled? Otherwise try to find a minimal configuration that causes the issue. If you can, try actually unplugging the irrelevant devices for testing.

Once you find a minimal configuration a log with PROTON_LOG=+alsa,+mmdevapi,+pulse %command% (note the lack +relay) should shed some light.

@ivyl will do the actual test at minimum in two hours, unfortunately until then I have to finish a work thing. But I already know some of your questions.

I also believed it was an issue given by the 7.1 at first but that didn't seem to be the case. As far as I noticed I can play well with Proton 8 as long as neither of webcam or capture card are enabled. If any of the two is it dies. If they are both disabled they work also with 7.1.

@ivyl I have done the tests as you asked and found out couple of things:

This one here is the most minimal configuration to make the game run fin on Proton 8 with my hardware:

Requested log:
steam-617290.log

So, I noticed couple of interesting things.

1. Having or not the 7.1 audio enabled doesn't effect anything. I tested that first with stereo as asked and then once purposely with 7.1. It didn't change anything.

2. I tried increasing the number of output devices, the game won't care at all if there is more than one enabled

3. The game will die like described originally whenever there is more than a single audio input. It doesn't really care that it's the webcam or the capture card. If I leave only the capture card in and not the blue yeti microphone for example it will still work. But if there is more than a single audio input device it will crash and burn.

4. This same exact issue is reproduced with many other titles, like for example DRG as guessed by @alasky17, I have done the same exact experiments for that game!

Here are the logs about that, same exact behavior and procedure as described above!
steam-548430.log

@alasky17 @kisak-valve

@Plarpoon this is the same issue with DSOUND.dll segfaulting as I reported against Dying Light 2. (I came here to report the same issue against Remnant: FtA.

For me, it is related to my SteelSeries Arctis Pro Wireless and GameDAC. If I unplug the DAC, the game launches and runs fine.

A workaround is to replace dsound.dll under Proton 8/Proton Experimental with the one from Proton 7, see https://github.com/ValveSoftware/Proton/issues/5542#issuecomment-1525075438.

I wrote a couple of bash scripts to replace/restore dsound.dll, you can just update the source_path and dest_path to point to wherever you steam common is.

#!/bin/bash

# Source and destination paths
source_path="<steam_lib>/steamapps/common/Proton 7.0/dist/lib64/wine/x86_64-windows"
dest_path="<steam_lib>/steamapps/common/Proton - Experimental/files/lib64/wine/x86_64-windows"

# Check if the source file exists
if [ -e "$source_path/dsound.dll" ]; then
    # Check if the destination file exists
    if [ -e "$dest_path/dsound.dll" ]; then
        # Create a backup of the existing dsound.dll
        mv "$dest_path/dsound.dll" "$dest_path/dsound.dll.bak"
        if [ $? -eq 0 ]; then
            echo "Existing dsound.dll backed up to dsound.dll.bak."
        else
            echo "Error: Unable to create a backup of dsound.dll."
            exit 1
        fi
    fi

    # Copy dsound.dll from the source to the destination
    cp "$source_path/dsound.dll" "$dest_path/dsound.dll"
    
    # Check if the copy was successful
    if [ $? -eq 0 ]; then
        echo "dsound.dll copied and replaced successfully."
    else
        echo "Error: Unable to copy dsound.dll."
        # If the copy fails, restore the backup
        if [ -e "$dest_path/dsound.dll.bak" ]; then
            mv "$dest_path/dsound.dll.bak" "$dest_path/dsound.dll"
            echo "Backup restored."
        fi
    fi
else
    echo "Error: dsound.dll not found in the source directory."
fi

#!/bin/bash

# Destination path
dest_path="<steam_lib>/steamapps/common/Proton - Experimental/files/lib64/wine/x86_64-windows"

# Check if the backup file exists
if [ -e "$dest_path/dsound.dll.bak" ]; then
    # Restore the backup to dsound.dll
    mv "$dest_path/dsound.dll.bak" "$dest_path/dsound.dll"
    
    # Check if the restore was successful
    if [ $? -eq 0 ]; then
        echo "Backup of dsound.dll restored successfully."
    else
        echo "Error: Unable to restore the backup of dsound.dll."
    fi
else
    echo "Error: Backup of dsound.dll not found."
fi

@rcbevans I think you have perfectly nailed the issue honestly. The proper way to deal with this issue is probably to ship a working version of DSOUND.DLL natively into the future Proton versions so that less technically involved users can benefit from it too. The workaround that you provided for now it's great and I love it, thank you a lot!

It's weird that the old version fixes the issue for you. There do not seem to be any significant code changes between 7.0 and 8.0 that could explain this.

@rcbevans Can you try with test-dsound beta branch of experimental (find Proton Experimental in Steam's library -> right click -> properties -> betas)? There's a slight chance that it will fix the issue. If not I'll may ask you later for some extra tests using a build that has much more logging added.

@ivyl I know you did not ask me but I also tested it and it works perfectly well with the DSOUND beta you mentioned!

First try smooth run 😄

I also had the same issue anyway.

Is the DSOUND beta going to be merged to Proton before Proton 9?

I don't mean to have an definitive answer if not present, even just to understand if it's supposed to be merged in that timeframe in case it actually is merged.

@Plarpoon thanks for checking! I'm upstreaming the changes in question and I'm going to cherry-pick them into experimental once it gets accepted. If everything goes right those will be a part of next experimental release and 8.0-5 (8.0-4 is already in release candidate phase).

I'm also waiting for other users to confirm that it's fixed by the change. While the change is correct and removes bits that were crashing I see no way it could have crashed in the first place just from the code or generated assembly... I see EOSSDK-Win64-Shipping.dll in the stack traces and that's really the only common thing between the games that are crashing for you (Remnant, Dying Light 2). So I wouldn't be surprised if this was some weird interaction with EOS.

I don't think Deep Rock Galactic uses it though and I believe it also had some problems in the past? If you could get a crash log with PROTON_LOG=+pulse,+mmdevapi,+dsound %command% that would be great.

@ivyl That sounds like absolutely amazing news, sorry for asking me again but just want to be sure, do you want a crash log of DRG and not Remnant?

Yes. Deep Rock Galactic please :-)

Here is Deep Rock Galactic using regular Proton Experimental
steam-548430.log

This one like expected hard crashed during the initial loading screen. In other words it opens the window of the game but it cannot load into the 3D environment. More of it it's described here in great detail.

There is also an analysis of the problem which you are already familiar with that I achieved mostly thanks to @kisak-valve, I invited other users to talk about it in this issue and it seems relevant to the test-dsound beta.
https://github.com/ValveSoftware/Proton/issues/6964

This one is a report of DRG with the test-dsound beta enabled. Unlike the standard Proton-Experimental this one did not crash and started playing flawlessly. I had to manually exit to desktop.

steam-548430.log

If I can be of any other use whatsoever just let me know @ivyl, I switched months ago to a full Linux setup so the only way I have to play all of my games is thanks to people like you. If I can do some testing to reciprocate somehow the effort I am more than glad, in that case feel free to ping me or contact me at my email at any moment! (it's in my GitHub bio)

p.s. Off-topic but I am never going to thank you all enough for having found a fix in here at that Battle.Net bug that keeps on wanting to update in loop.

Thank you, this was extremely helpful! I think I've found the root-cause. Including all the monitors (virtual input that's basically a mirrored output) you seem to have 11 of capture devices:

4078.372:012c:0184:trace:dsound:send_device Calling back with {25da76d0-033c-4235-9002-19f48894ac6f} (L"PulseAudio")
4078.375:012c:0184:trace:dsound:send_device Calling back with {14439992-ed74-4f23-8b4f-2ebc164830d3} (L"USB Audio Line In")
4078.377:012c:0184:trace:dsound:send_device Calling back with {1ee166dd-a156-41cf-bc7d-de3e68dbdd3a} (L"Monitor of USB Audio S/PDIF Out")
4078.381:012c:0184:trace:dsound:send_device Calling back with {3f7c5f1c-c7bb-4a99-a93b-8fbd278a5c51} (L"BRIO Ultra HD Webcam Analog Stereo")
4078.386:012c:0184:trace:dsound:send_device Calling back with {5009cf7f-e802-4be1-940c-fc7bbd3d19b8} (L"USB Audio Front Microphone")
4078.390:012c:0184:trace:dsound:send_device Calling back with {53a0d176-88c4-472c-b86c-071a183e42a9} (L"Monitor of GA102 High Definition Audio Controller")
4078.394:012c:0184:trace:dsound:send_device Calling back with {603e5417-8cdf-447c-aad2-446acc1594b4} (L"Monitor of Arctis Pro Wireless Chat")
4078.399:012c:0184:trace:dsound:send_device Calling back with {690033ae-4571-4ac0-bf28-537e374b2993} (L"Monitor of USB Audio Speakers")
4078.402:012c:0184:trace:dsound:send_device Calling back with {7182ef0e-3572-42d5-bf93-6e34ef81488d} (L"Monitor of Arctis Pro Wireless Game")
4078.404:012c:0184:trace:dsound:send_device Calling back with {7c4929d7-d2fe-4ca5-807b-98f367ffa469} (L"Monitor of USB Audio Front Headphones")
4078.407:012c:0184:trace:dsound:send_device Calling back with {8a5e9efc-0add-450d-a1d3-f105b8f69827} (L"USB Audio Microphone")

This exceeds the number of GUIDs that can be stored in DSOUND_capture_guids which is MAXWAVEDRIVERS = 10. This is stored in memory just next to critical section and capturer device list. The pointers stored there get overridden and dereferencing them is catastrophic.

The first test branch removes the list (it's unused) which leaves much more space than intended for the GUID array due to how things are aligned and thus mitigates the crash.

I've created test-dsound2 beta branch that naïvely bumps the limit of capture devices to 30. Can you test that with all three games? If that's it I'll make a more proper patch that also checks the bounds tomorrow.

Sure, no issues whatsoever, do you have a specific debug string of parameters you want me to use or should I keep on using the previous one @ivyl?

The previous one is perfect.

Oke @ivyl, gimme a few seconds and I will send you everyhing. You said 3 games, which one is the third one?

I know DRG and Remnant, is the third one perhaps Titanfall? Because in that case I have only Titanfall 2 installed at the moment and I might need some time to download the first one.

Hopefully things won't crash. Then logs are not necessary :-)

Dying Light 2, at least that's a game that @rcbevans was experiencing crashes with.

I unfortunately do not own that game... I am sorry (hopefully one day)

I have fantastic news @ivyl, both games are working perfectly fine and flawlessly. You found the issue!

Here is Deep Rock Galactic
steam-548430.log

Here is Remnant from the Ashes
steam-617290.log

If I can get confirmation that this issue is fixed I will close it even now adding a redirect to one of your last posts @ivyl.

As far as I can see the problem is completely resolved, I am now waiting for more feedback 😃

Thank you for everything you did in the meantime and feel free to ping me if you need to test something in the future! 🦖

Audio stuttering in Proton – Remnant: From the Ashes (UE4) – Linux Mint 22.3

Problem

The game has intermittent audio stuttering / dropouts.

Symptoms:

• short sound interruptions
• affects music and sound effects
• occur immediately after the game starts, even during the splash screen
• FPS remains stable

The issue appears only in this game after upgrade Linux Mint 21.3 → 22.3. Other games work correctly

Proton versions tested

All show the same behaviour.
Tested:

• Proton 8
• Proton 9
• Proton 10
• Proton Experimental
• Proton Hotfix
• GE-Proton (latest)

Wine prefix was cleared when changing Proton by deleting
~/.steam/debian-installation/steamapps/compatdata/617290/

PipeWire observations

When the game runs, PipeWire shows two audio streams. (Other games make only one.)

pw-top

Both currently report:

quantum = 1024

Formats:

• S16LE
• F32LE

Observations from manual muting tests:

pactl set-sink-input-mute <ID> 1

• muting S16LE removes the audible game sound
• muting F32LE does not change the sound

This suggests that the primary game audio output is S16LE.

Therefore the role of the F32LE stream is currently unknown and it is not confirmed to be related to the issue. However, the two audio streams in this game are the only difference from other games that have no audio issues on my system.

ERR=176 value for alsa_output appeared after a few hours of observation. It doesn't increase when the game starts. I don't think it's worth paying attention to.

UE4 audio test

Launch option tested:

-NoSound

Result:

• the main game audio disappears
• one audio stream F32LE still remains active in PipeWire

This confirms that the option disables the main mix but does not fully remove the audio device.

Launch options tested

The following launch options were tested:

PROTON_NO_ESYNC=1 %command%
PROTON_NO_FSYNC=1 %command%
PROTON_USE_WINED3D=1 %command%

PULSE_LATENCY_MSEC=60 %command%
PULSE_LATENCY_MSEC=120 %command%

PIPEWIRE_LATENCY=1024/48000 %command%
PIPEWIRE_LATENCY=2048/48000 %command%

None of these changed the behaviour.

CPU governor test

sudo cpupower frequency-set -g performance

Result:

No change. Audio stuttering persists.

PipeWire buffer testing

Observed stream values during gameplay:

quantum Remnant = 1024

Changing latency / buffer settings did not resolve the problem.

Logs

PipeWire logs show:

• no XRUN
• no buffer underruns

Summary

• Audio stuttering occurs only in Remnant: From the Ashes
• Happens across all tested Proton versions
• PipeWire shows two streams (S16LE and F32LE)
• Audible sound comes from S16LE
• Buffer, latency and CPU governor tests had no effect
• -NoSound removes the main sound but leaves one audio stream active
• Issue appeared after upgrading Linux Mint 21.3 → 22.3

Other diagnostic data

PipeWire logs:

journalctl --user -b | grep pipewire

systemd[1600]: Listening on pipewire-pulse.socket - PipeWire PulseAudio.
systemd[1600]: Listening on pipewire.socket - PipeWire Multimedia System Sockets.
systemd[1600]: Started pipewire.service - PipeWire Multimedia Service.
systemd[1600]: Started pipewire-pulse.service - PipeWire PulseAudio.
pipewire[1615]: mod.jackdbus-detect: Failed to receive jackdbus reply: org.freedesktop.DBus.Error.ServiceUnknown: The name org.jackaudio.service was not provided by any .service files

Steam Proton log:

PROTON_LOG=1 %command%

steam-617290.log

Any guidance on debugging the UE4 audio mixer under Proton would be helpful.

@nickolaru-a11y given that these symptoms appeared after updating your distro, it is unlikely this is a proton issues. Still I checked on my desktop and deck with proton 10 and experimental and couldn't hear any issues. How often does the issue crop up? from your text I imagine it's often, but it'd be good to have explicit confirmation.

For this sort of issue I'd first suspect pipewire/wireplumber changes. Deck has wireplumber 0.5.7 and pipewire 1.2.7 while my desktop has 0.5.13 and 1.6.0 respectively. Unfortunately, there doesn't seem to be a way to check mint packages online, but if the ones shipped with mint are older, it might be worth a try seeing if you can update them further (though ideally after setting a backup).

As for the formats, I also see both being used by the game on my end too, so probably unrelated to your issue.

How often does the issue crop up? from your text I imagine it's often, but it'd be good to have explicit confirmation.

Allways, immediately after the game starts, even during the splash screen.

Thanks for checking this on your systems.

pipewire --version

pipewire
Compiled with libpipewire 1.0.5
Linked with libpipewire 1.0.5

wireplumber --version

wireplumber
Compiled with libwireplumber 0.4.17
Linked with libwireplumber 0.4.17

apt list --installed | grep pipewire

gstreamer1.0-pipewire/noble-updates,now 1.0.5-1ubuntu3.2 amd64 [установлен]
libpipewire-0.3-0t64/noble-updates,now 1.0.5-1ubuntu3.2 amd64 [установлен, автоматически]
libpipewire-0.3-common/noble-updates,noble-updates,now 1.0.5-1ubuntu3.2 all [установлен, автоматически]
libpipewire-0.3-modules/noble-updates,now 1.0.5-1ubuntu3.2 amd64 [установлен, автоматически]
pipewire-alsa/noble-updates,now 1.0.5-1ubuntu3.2 amd64 [установлен]
pipewire-audio/noble-updates,noble-updates,now 1.0.5-1ubuntu3.2 all [установлен]
pipewire-bin/noble-updates,now 1.0.5-1ubuntu3.2 amd64 [установлен, автоматически]
pipewire-pulse/noble-updates,now 1.0.5-1ubuntu3.2 amd64 [установлен]
pipewire/noble-updates,now 1.0.5-1ubuntu3.2 amd64 [установлен, автоматически]
vlc-plugin-pipewire/noble,now 3-3build2 amd64 [установлен]

apt list --installed | grep wireplumber

libwireplumber-0.4-0/noble-updates,now 0.4.17-1ubuntu4.1 amd64 [установлен, автоматически]
wireplumber/noble-updates,now 0.4.17-1ubuntu4.1 amd64 [установлен]

I attempted to install newer audio packages from the PipeWire upstream PPA, but the versions available there for my distribution are still older than the ones you mentioned (WirePlumber 0.5.7 / PipeWire 1.2.7).

Current situation on my system (Linux Mint 22.3):

So even with the PPA, the system remains on the WirePlumber 0.4 branch, while your tests use WirePlumber 0.5 and newer PipeWire versions.

Given that, the most reasonable next step on my side is probably to wait until newer PipeWire/WirePlumber versions become available for the distribution and then re-test the game.

Thanks for taking the time to investigate this.