Proton: DOOM 2016 sound is horribly broken (379720)

[kakra]

Throughout all Proton versions, sound in Doom is crackling and distorted a lot. It sometimes works when starting it with higher priority but only during the loading screen while the logos shows. When the menu screen starts, sound stutters, is distorted, or crackling horribly with many buffer drop outs.

I know this is a problem of Wine 3.7 which Proton is based on. Since then, Wine vanilla had some pulseaudio patches which finally fixed the problems here. A few other games are affected, too:

1. Kingdoms of Amalur has this problem, too.
2. Witcher 3 has this problem sometimes: It's either working from the start or shows sound issues from the start.

I think pulseaudio stability in wine heavily depends on system load during wine startup. This seems to have been fixed later.

The game itself has no performance issues: Playing with Vulkan, it constantly works at the vsync limit of 60 fps with GPU/CPU load way below 50% most of the time.

Sys info:
https://gist.github.com/kakra/cb95087ed58cb40ca7f9c0e5109aabce

[kakra]

This seems to be fixed now for Doom (with 3.7-5)... But now gameplay freezes after some time (music continues to play). I need to SIGKILL the process.

[zaggynl]

Same sound issue and workaround here: https://github.com/ValveSoftware/Proton/issues/396

As for the GPU freezes:
https://github.com/ValveSoftware/Proton/issues/1070#issuecomment-417657503
Workaround for me was to switch to XFCE, disabling Steam overlay might also help.
Interesting to see this also exists on Nvidia!

Edit: Proton 3.7.5 beta did not resolve the sound issue for me.

[kakra]

For Rise of the Tomb Raider (native Vulkan) the freezes can mostly be resolved by disabling the overlay. So its counter-intuitive to enable it here... But well, my overlay is enabled. Seems stable for Rise since some nvidia update.

I'll try without overlay and report back.

[kakra]

The sound issue is back. I think it was pure luck that it worked correctly in one of maybe 100 launches of the game.

[johan-bjareholt]

The most common reason for crackling on Wine is usually due to too high/low buffering.

https://wiki.winehq.org/Sound#PulseAudio

Preferably you should just make sure that the PULSE_LATENCY_MSEC variable is not overriden by your system, but if you just want a quick fix you can test to manually set it (maybe test to set it to 5, 30 or 90 and see if it works).

It sometimes works when starting it with higher priority but only during the loading screen while the logos shows.

This is quite a strong indicator that some kind over buffer overrun is occuring.

[kakra]

I do not set this variable because it caused more problems than it solved in the past (including freezing games). Of course I tried settings this nevertheless without success. I'm currently rebasing proton to newer wine versions. With the pulseaudio patches of proton removed and rebased to wine 3.9 it looks very promising currently. But the problem seems to be caused (or solved) by something outside of pulseaudio in wine. Once I finished rebasing, I will reapply the pulseaudio patches (including fixes that @aeikum provided) to cross-check that.

Also, there's comments in the changelogs that this variable no longer has an effect with the updated winepulse drivers and should not be set.

[kakra]

I've rebased to wine 3.12, sound seems to be OK always every time now:
https://github.com/kakra/wine/releases/tag/wine-proton_3.7-3.12-unofficial

I cannot currently rebase to any later wine version because this breaks Vulkan (or even any game) for me. I think I messed up somewhere during rebase or some of the more complicated patches (i.e. esync) are incompatible. I see that there're esync patches based on 3.10 available from the author, I'll have to investigate this. Proton 3.7 patches completely fail to rebase (at least conflicts won't easily resolve) onto wine 3.15. This is mostly related to esync.

At least sound is okay now so I'll stick with that version for a while.

[kakra]

I'm pretty sure it has to do with something like 44.1 kHz vs 48 kHz vs 96 kHz. Configuring anything else than 44.1 kHz in pulseaudio has the potential to break the sound im Doom. Strange is, tho, that Wine itself seems to initialize/probe the audio device with 48 kHz (according to the code).

This also does not explain why it occurs only sometimes. But it explains pretty much every issue I'm seeing: If input vs output rate only slightly differ (48 vs 44.1 kHz), then I get the effect that I hear most of the times: A constant distortion which sounds like too short buffers. If input vs output rate differ much (96 vs 48 or 44.1 kHz), I hear what sounds like double pitch, double speed. This affects only some sound effects in the game (usually ambient speech). This kind of effect was rare. But even more rare was getting correct sound all the way through the game. Configuring pulseaudio for 44.1 kHz (or leaving defaults) seemed to have fixed this. Configuring it to 96 kHz has total potential of breaking the sound but just in this game. So maybe it's a bug in the game not in Wine?

I can only conclude that something really weird is happening when one of the involved components has to convert between different audio rates. Is it the game having a bug? Is it Wine that sometimes gets confused while probing the pulseaudio device? I don't think it's a bug in pulseaudio itself because outside of Wine it works perfectly well with these settings.

We've seen different bugs here. The one above is still present. The others were fixed for me (out-of-sync buffers with buffers playing backwards in time sometimes) thanks to the work of @aeikum and the current patches in wine-staging.

It took a while to figure this out because this 48/96 kHz config is deployed since months or even years here without causing trouble.

I've updated my wine-proton build with the latest patches if someone wants to check:
https://github.com/kakra/wine/releases/tag/wine-proton_3.7-3.12-unofficial-1

[zaggynl]

I've tried your build but the sound issue appears to persist for Doom and PoE, any way to verify I'm using your build? I've got the Proton beta selected and I've copied the dist folder over the existing folder.

[kakra]

@zaggynl Navigate to the Proton folder in SteamApps/common for the version you're using. Then run tar df /path/to/build/dist...tar.xz. It should show no output, otherwise it would list any file that differs. It looks like Steam sometimes likes to reset the files. If you want to restore my build, just run the same command with xf instead of df.

Please also verify that you're not setting sample frequencies in /etc/pulse/daemon.conf or .config/pulse/... if you're using a config in your $HOME (see man pulse-daemon.conf for possible locations of the config file).

If you do not set sample rates, try to set different combinations of 44100 and 48000 for both default-sample-rate and alternate-sample-rate. I currently suspect that this has something to do with it and is a bug somewhere lurking around in the game or wine. Report back about your findings.

But first check if you use my latest build which includes the latest patches from Andrew (see link in previous comment, the proton_3.7-3.12-1 version).

I didn't have audio problems in PoE. Would you mind sending me a recording of the broken sound (PM [email protected], or here if you prefer) so I can hear if we are experiencing the same issue? I can only compare Doom, but recorded samples from both games are fine.

PS: If you're using multiple steam libraries, chances are that Proton got installed into multiple libraries - it seems undefined which one is used then. So if in doubt, replace them all.

BTW: Sound in Doom is currently working fine here (reproducible) even when compiling wine in the background. So it's no longer a CPU/IO load problem for me. This particular load problem seems to have been fixed by Andrew (included in my updated build).

[zaggynl]

Thanks!
Doom started in windowed mode on my left monitor instead of the right primary one.
Sound issue persists but the the distortion is not recorded when using kazam, I've done a recording by mic on my headphones in the past for Doom: https://www.youtube.com/watch?v=_PdEG8wh0WM
Sounds similar when starting PoE: https://youtu.be/6aJatBuRZ1g

Recorded with Audacity, combined still image with audio with ffmpeg: ffmpeg -loop 1 -r 1 -i poelogo.png -i poe_distortion.wav -c:a copy -shortest poegarbled.avi

No changes made to daemon.conf, using default in ubuntu 18.04: http://paste.ubuntu.com/p/Rz7TH7jC7j/

Edit:
Tried 44100/44100 and 48000/48000 for default- and alternate-sample-rate

Edit2:
Killed pulseaudio with killall pulseaudio and started it with: pulseaudio --log-level=4 --log-target=file:/home/az/Downloads/pulselog20180910.txt
Doom: http://paste.ubuntu.com/p/K9bk4hhj6s/
PoE:http://paste.ubuntu.com/p/FW763JThnZ/

With tsched=0 change as per: https://github.com/ValveSoftware/Proton/issues/396 sound is clear
Doom: http://paste.ubuntu.com/p/DJWBPtD9Br/
PoE: http://paste.ubuntu.com/p/6GqBBbX33M/

D: [alsa-sink-ctxfi] sink.c: alsa_output.pci-0000_09_02.0.analog-stereo: Found underrun 216 bytes ago (17364 bytes ahead in playback buffer)
Appears to be the issue, not sure what the proper fix is.

pulseaudio 11.1

Edit3:
Installed lowlatency kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18.7/, did not make a difference.
PoE pulseaudio output: http://paste.ubuntu.com/p/bxMVz5KhkK/

[kakra]

Sounds a lot like my issue when I use 96 kHz... It's not the timing related issue that was fixed as far as I can tell. If possible, do a sound recording of Doom. Shortly after a first starting point in level 1 (or 2? can't remember), there should be a female ambient voice. I'm interested if it plays back in normal speed or in some high pitched faster speed with audio dropouts. It's usually only with the ambient voices in the game.

Also, here's a debug build. Edit user_settings.py to say "WINEDEBUG": "trace+pulse" (it's in the Proton directory, remember to remove it later, logging can be a performance killer). Start Doom with my updated build, then quit from the title screen. In $HOME it should have created steam-379720.log. Specifically, I am interested in the following output (no need to send the whole file):

# egrep '(sampling format|period)' ~/steam-379720.log
# my output when it works:
0034:trace:pulse:pulse_probe_settings pulse_{def,min}_period [0]: 208.
0034:trace:pulse:pulse_probe_settings Selected sampling format: { .rate=48000, .format=5, .channels=6 }.
0034:trace:pulse:pulse_probe_settings pulse_{def,min}_period [1]: 1250.
0034:trace:pulse:pulse_probe_settings Selected sampling format: { .rate=16000, .format=5, .channels=1 }.

Here the debug build:
https://drive.google.com/open?id=1Q41xwwZdB1cCW-LG20HP1ZOUFOxoBt-P
(sha1sum 4160aa27c4e658c1b1587731e0bd18cc091b78cc)

Since I only see it with 96 kHz and my system doesn't seem overloaded or CPU-bound, I wonder if this is an integer overflow somewhere which is causing this. Will be hard to find without deep knowledge of the code.

[zaggynl]

That took a while (I need sleep):

0030:trace:pulse:pulse_probe_settings pulse_{def,min}_period [0]: 226
0030:trace:pulse:pulse_probe_settings selected sampling format: { .rate=44100, .format=5, .channels=2 }
0030:trace:pulse:pulse_probe_settings pulse_{def,min}_period [1]: 226
0030:trace:pulse:pulse_probe_settings selected sampling format: { .rate=44100, .format=5, .channels=2 }

[kakra]

@zaggynl I did two recordings with OBS studio... Apparently, NVENC doesn't work here so loading takes quite a time and movement is a bit jerky (usually it runs 60 fps with pretty fast loading):
https://youtu.be/yN6mnBYR4e0

For the second one, I raised OBS priority to SCHED_ISO and IO prio = 0 to see if it helps recording but it hurts game performance a lot, I even have sound drop-outs:
https://youtu.be/o--kXOc_718

Black screen at the beginning is starting the game from Steam. I'm not sure why it always shows the first loading screen right before the title when recording. Usually it's a one-time occurrence. But these videos showed me that Doom is quite heavy on the loading screens, it took awfully long to load while recording. It's definitely CPU bound there.

First time playing this level... Argh, now it saved my messy progress... :-)

[kakra]

@zaggynl Does the debug log change when you switch pulseaudio to 48k mode?

[kakra]

tsched=0 makes no difference here (it used to in older wine versions for The Witcher 3 back when I played it a lot). I also had the wrong-screen issue after I cherry-picked some updates from Proton 3.7... There were some fullscreen hack fixes, one explicitly mentioning Doom. I had to Alt+Enter the game into window mode because I could only see one quarter of it, then switch it back to the correct monitor in the settings, since then: everything fine.

[zaggynl]

Odd how it's so different across PCs!
Tried with 48k:

002f:trace:pulse:pulse_probe_settings pulse_{def,min}_period [0]: 208
002f:trace:pulse:pulse_probe_settings selected sampling format: { .rate=48000, .format=5, .channels=2 }
002f:trace:pulse:pulse_probe_settings pulse_{def,min}_period [1]: 208
002f:trace:pulse:pulse_probe_settings selected sampling format: { .rate=48000, .format=5, .channels=2 }

[kakra]

So your card supports both correctly... But the game still runs distorted?

[zaggynl]

Indeed, and the odd thing is any other audio playing app say firefox with youtube or deadbeef will also sound distorted until the game playing through wine is exited.

[kakra]

This sounds a lot like things become broken within pulseaudio. This is an interesting hint...

Meanwhile, you could try the following changes in pulse/daemon.conf:

; may reduce CPU usage by not doing unnecessary resampling
avoid-resampling = true

; may reduce CPU usage by using the HW mixer instead of software
flat-volumes = yes

; try different methods here, see man pulse-daemon.conf
resample-method = speex-float-1

This is the setup I am using. It may also help to fiddle around with default-fragments and default-fragment-size-msec so usually that only made the problem worse for me. But you may be lucky. :-)

[zaggynl]

Definitely is Pulseaudio, I mistyped one of those and pulseaudio didn't start, no more distortion!

Tried

avoid-resampling = true
flat-volumes = yes
resample-method = speex-float-1

but made no difference, I'll try fiddling with those fragment options tomorrow.

[kakra]

Well... Wait... While the game runs, would it have started pulseaudio by itself then? PA has some sort of autospawn capability...

OTOH, if it does autospawn and it's not running, it's also not using winepulse.drv within wine. So we still have to candidates to look into.

[odysei]

In my case, I see that pure 44100 is not good enough. I had too add PULSE_LATENCY_MSEC=60 to start the game (steam). Alternative frequencies (with resampling; my nominal use is 192) are broken no matter the variable. Strangely, it ran fine for ~60 min and started crackling again.

[kakra]

@odysei Maybe some variable to sync the buffers is drifting over time due to rounding errors?

[odysei]

@kakra this would make sense. I will post more if I spot something new.

[ibrokemypie]

I had crackly sound and solved it by enabling tsched, enabling avoid_resampling and setting default samplerate to 48000

[odysei]

I can add that while PULSE_LATENCY_MSEC=60 starts crackling after 40--60 mins, PULSE_LATENCY_MSEC=90 seems to run fine forever.

[kakra]

@odysei That's really odd... But it is a helpful hint for people still with sound issues. For me it's fixed with 48000 and using a later wine version than what Proton is based off.

[kakra]

I finally was successful with a big update, here's my build rebased to wine 3.16 with an amount of additional fixes and improvements. Do you guys still see problems with this build:
https://github.com/kakra/wine/releases/tag/wine-proton_3.7-3.16-unofficial-1

[zaggynl]

Sorry for the late response, garbled sound in DOOM 2016 still occurs in Proton 3.16

Tested again with your build but made no difference for me in DOOM 2016 .

[kakra]

@zaggynl Please install rtkit-daemon or RealtimeKit (or whatever your distribution calls it) and configure it to be enabled for your user. Please also add the following pretending that your user is part of the unix group "users":

# /etc/security/limits.d/99-wine-priorities.conf
@users - rtprio 90
@users - nice -15

This change needs a reboot to be applied. It enables my wine version to properly use priorities for threads and processes. I recommend running a kernel with SCHED_ISO support if you're still having issues, try the CK kernel as a supported kernel.

Also, do not enable any pulseaudio tweaks except for tsched if your hardware needs that. The defaults should work just fine.

Then please retry with the following testing version:
https://keybase.pub/hurikhan77/wine-proton-unofficial/dxvk-dist-wine-3.19-625-g917b6894cf2.tar.xz

I recommend using Vulkan mode for DOOM (defaults to OpenGL, switch it in the advanced options). If you want to use DX11 games, you may want to switch proton to not use DXVK because DXVK is already built-in as winelib including a minor optimization ("PROTON_USE_WINED3D": "1").

[Cxpher]

Works the moment i dropped down to 48 khz from 96 khz in PA config.

No idea why 96 khz resampling borks the sound. Works fine with everything else.

24 bit 48 khz works for me anyway.

[kakra]

@Cxpher I can confirm from memory that this improved the situation but I'm not sure why... I may retest this with my current patched version.

[Cxpher]

@kakra

The default on Windows is 44.1 hz audio at 16 or 24 bit depth depending on hardware if I'm not wrong.

Most gamers don't even change it.

96 khz resampling at 24 bit is nice but not a huge biggie.

Anyone able to test if the bug exists on Windows natively? Could be carried over.

[kakra]

@Cxpher Pulseaudio lets the user define two sampling rates so it could fall back to the other to prevent superfluous resampling. By default this is 44100 and 48000. While tracing the sampling formats that games use when opening the device, I saw that some games use 44100, others use 48000, and some use a mix of both.

My idea was always that upsampling would be better than downsampling (because it introduces no obvious audio artifacts), thus I put 48000 and 96000 as alternatives into pulseaudio. It worked fine and some games even sounded "clearer" with it (I cannot really tell, it didn't sound different or better, just the sound felt more clear). But DOOM has problems with it. DOOM seems to have two problems:

One is crackling which results from problematic timing, I improved this in my branch, and later also Proton improved it from the other side by adjusting winpulse.drv code. This can also be caused to too low CPU power to keep up with buffering during audio rendering.

Another is sound playing too fast (but not pitched wrong). This can be somewhat explained by 48k vs 96k rates tho it doesn't explain why the pitch was still okay. The audio processing seem to do some strange things and totally messes up. It probably jumped every second buffer or so. DOOM was the only game showing this problem, and it showed up only for ambient voice/speech playback (but not music nor any sounds).

If the 48/96 problem is still present, it should show again as soon as I change my PA config again. But with inclusion of FAudio, the audio threads seem to use a lot more CPU (70% on one core for some games), so I don't think that my system could even cope with such high sampling rates then. I'd probably see problem "one" again then.

[Cxpher]

Hi,

My rates now are set to 48k and alternative as 44.1k. Previously, it was
96k and 48k.

This gives me the impression that it does not use alternative since there's
no reason for it to fallback. It uses 96k instead of 48k unless 48k is set
to primary since sound still plays. Just that it does not play properly in
menus.

Setting your primary to 48k and alternative to 44.1k solves this.

The resampling format i use is speex-10. This combined with 24 bit audio at
48k sampling rate already gives me better than Windows defaults on the same
rig.

I coukd change that to soxr-vhq and 96k for even better audio but that
introduces a bit more latency and it actually does make a difference with
Bluetooth audio through wine.

As such, the workaround is acceptable.

On Wed, 9 Jan 2019, 19:47 Kai Krakow <[email protected] wrote:

@Cxpher https://github.com/Cxpher Pulseaudio let's the user define two
sampling rates so it could fall back to the other to prevent superfluous
resampling. By default this is 44100 and 48000. While tracing the sampling
formats that games use when opening the device, I saw that some games use
44100, others use 48000, and some use a mix of both.

My idea was always that upsampling would be better than downsampling
(because it introduces no obvious audio artifacts), thus I put 48000 and
96000 as alternatives into pulseaudio. It worked fine and some games even
sounded "clearer" with it (I cannot really tell, it didn't sound different
or better, just the sound felt more clear). But DOOM has problems with it.
DOOM seems to have two problems:

One is crackling which results from problematic timing, I improved this in
my branch, and later also Proton improved it from the other side by
adjusting winpulse.drv code. This can also be caused to too low CPU power
to keep up with buffering during audio rendering.

Another is sound playing too fast (but not pitched wrong). This can be
somewhat explained by 48k vs 96k rates tho it doesn't explain why the pitch
was still okay. The audio processing seem to do some strange things and
totally messes up. It probably jumped every second buffer or so. DOOM was
the only game showing this problem, and it showed up only for ambient
voice/speech playback (but not music nor any sounds).

If the 48/96 problem is still present, it should show again as soon as I
change my PA config again. But with inclusion of FAudio, the audio threads
seem to use a lot more CPU (70% on one core for some games), so I don't
think that my system could even cope with such high sampling rates then.
I'd probably see problem "one" again then.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1114#issuecomment-452669182,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Arbrzn7Fo_GAp_IS_kx3ohdypjAi9a2wks5vBdbmgaJpZM4WWITS
.

[koubinovski]

OS: Debian GNU/Linux 9.6 (stretch) (64 bits)KERNEL: 4.20.0CPU: AMD Phenom II X6 1090TGPU: NVIDIA GeForce GTX 750GPU DRIVER: NVIDIA 415.22.01RAM: 6 GB

for me in /etc/pulse/daemon.conf : replace ; default-sample-rate = 44100 by ; default-sample-rate = 48000 and restart computer,it solved sound problems with my doom 2016.

[Cxpher]

A sample rate of 48000 is adequate for default. Don't need to drop that
down to 44100.

On Fri, 11 Jan 2019, 18:25 koubinovski <[email protected] wrote:

OS: Debian GNU/Linux 9.6 (stretch) (64 bits)KERNEL: 4.20.0CPU: AMD Phenom
II X6 1090TGPU: NVIDIA GeForce GTX 750GPU DRIVER: NVIDIA 415.22.01RAM: 6 GB

for me in /etc/pulse/daemon.conf : replace ; default-sample-rate = 44100
by ; default-sample-rate = 48000 and restart computer,it solved sound
problems with my doom 2016.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1114#issuecomment-453469976,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Arbrzkk8r7yunAd98alO8s7IvQyrARJbks5vCGa3gaJpZM4WWITS
.

[odysei]

Just for the record, Windows version runs fine @ both 96 and 192 kHz.

[Cxpher]

That's interesting!

It's what I wanted to know.

I wonder what happens if the default is set to 96 khz but resampling is set
as not preferred.

It's probably the way PA is resampling that causes it. Can likely be
submitted as a bug to PA.

On Sat, 12 Jan 2019, 18:39 Aurelijus Rinkevicius <[email protected]
wrote:

Just for the record, Windows version runs fine @ both 96 and 192 kHz.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1114#issuecomment-453737292,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ArbrznOso8hTHzlOpIDU-JY58gYhC88Vks5vCbt7gaJpZM4WWITS
.

[odysei]

Do you mean 'avoid-resampling = true' ?
It does not change the story in my case. Probably it allows the app to change the sampling rate, but the app (DOOM+wine+...) does not do it and sticks to whatever I have as default-sample-rate. Long story short, garbled sound stays garbled.
Since I need PULSE_LATENCY_MSEC=90 and 44.1 kHz for sound to work, IMHO this points to a buffer being broken.

[kakra]

AFAIR the wine code prefers 48000/32bit - and only falls back to what PA provides if it cannot successfully use that. (dlls/winepulse.drv/mmdevdrv.c@pulse_probe_settings)

[Cxpher]

96 khz works for other games in wine. Probably fallback to 48 khz in those
cases then?

And in Doom, it works but just does not work properly? So it does not
fallback?

On Sat, 12 Jan 2019, 21:04 Kai Krakow <[email protected] wrote:

AFAIR the wine code prefers 48000/32bit - and only falls back to what PA
provides if it cannot successfully use that. (
dlls/winepulse.drv/mmdevdrv.c@pulse_probe_settings)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1114#issuecomment-453745946,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Arbrzhbz_DARbxaakf1bizlK8uv39xXIks5vCd1wgaJpZM4WWITS
.

[mooninite]

This is a bug in the Wine pulseaudio driver. Forcing the usage of the Wine alsa driver using the registry editor stops the horrible audio clipping. I didn't have to change any Pulseaudio daemon settings or set any env variables. I run 24-bit/96kHz.

https://wiki.winehq.org/Useful_Registry_Keys - HKCU\Software\WineDrivers\Audio = "alsa"

[odysei]

In my case, alsa does not do the job. Although admittedly the distortion is different. As a matter of fact, with Audio set to "alsa" it sounded even worse. Anyway, still distorted.