Compatibility Report

@GreenEyedBear Could you please try the "bleeding-edge" beta branch of Proton Experimental to see if this fixes your audio issue? We've been working to fix several related issues and some of the fixes are not in the regular Proton Experimental build yet.

PS - Proton Hotfix always contains very short-lived versions (see https://github.com/ValveSoftware/Proton/wiki/Proton-Versions) so it is basically never worth the time to run a separate test there and I'd highly recommend just using experimental :)

@alasky17 apologies, I tried but it seems my 7GB or RAM simply aren't enough for the make install command to run without making my poor laptop freeze before it could complete. I'll probably wait until the bleeding-edge changes land in Experimental (when can I expect this to happen?) unless someone else is willing to do the test sooner. Regardless, thank you for your answer!

@GreenEyedBear Oh - I guess I was unclear with my instructions. I didn't mean to build yourself. bleeding-edge is available as a beta channel. If you search through your library for "Proton" and look in the "tools" section (as opposed to games), you will see a list of the Proton versions you have installed. If you go to the properties for Proton Experimental and look in the "Game Versions & Betas" tab, you will see a list of beta versions including "bleeding-edge". I would recommend switching back to the "default public version" after testing as it is more stable :)

Otherwise, we'll likely have a new experimental release some time this week - if you'd rather wait to test that, it is no problem at all and we'll be happy to hear your results then (and investigate further if you still see the issue). Thank you for the response!

@alasky17 Oops! Alright, I just tested the bleeding-edge branch as a beta version of Experimental. After playing for 16 minutes, the bug did not happen, so I assume this is fixed, considering how consistent the 15m27 was. Thank you!

@alasky17 Unfortunately I must amend my previous message. It turns out that the latest changes to Proton Experimental only partially solved the issue with audio. The current behavior is now:

• audio still cuts at 15m27 after the game starts
• audio resumes 20 seconds later. After this cut, the sound is back to normal (no glitch, no speed up)
• no further cuts after 30m, 45m etc

Verified on both bleeding edge and the main branch of Experimental (after downloading the Experimental update from 2 days ago).

I missed this during my test from 5 days ago because I was AFK during the cut and came back for the 16 minutes mark, when audio was already back to normal.

This is already much better than previously (we had to actually restart the game, now it's only a minor nuisance for 20 seconds) but I wanted to flag that there's still something going on.

@GreenEyedBear Thank you for the update! Could you get a log with PROTON_LOG=+pulse,+mmdevapi %command% with the audio cut? There is still a known issue which is "in progress" and hopefully we can use a log to confirm if this is that same issue or something separate :)

The remaining issue is even more complex, so the best way to fix this has not yet been determined but at least the problem is understood :)

@alasky17 Here's a segment from a few seconds before the cut to a few seconds after the audio came back: short.log. Full log would have been 190MB since it recorded the whole 15 minutes before it cut.

I suppose the bug happens between 1703.243 and 1723.729 (log's times), fits my "20 seconds" rough measurement and that's where all the "warn"s are in that log file: you can see a bunch of
warn:pulse:pulse_write_index_catchup write index did not advance.
and
warn:pulse:pulse_release_render_buffer 0xdee0ef40 PA buffer overflow.
That are nowhere to be found outside of that segment.
Also some numbers that are weirdly close to 2^63 like
trace:pulse:pulse_write_index_catchup stream 0xdee0ef40, runnind 1, read is ahead of write 9214357278457598856 bytes.
In fact if you look at all those "read is ahead of write %d" logs, you see there's exactly 2^11 of them (one every 0.01s on average), with the number decreasing by more or less 2^52 every time. Bug ends when that number finally reaches close to 0? Reminds me of floats binary encoding. Either way, looks fun, good luck!

@GreenEyedBear can you play with the following launch parameter and see if the issues persist? PROTON_USE_WOW64=1 %command%

@simifor I played with this setting on Experimental for 35 minutes and the issue did not occur

The audio issue appears to be completely solved in current Experimental (not bleeding edge, without using PROTON_USE_WOW64=1)