A couple of issues with Proton

[WarnerCK]

Running Proton games gives me really loud coil whine. It's not that the games themselves are working the GPU hard - it happens even with something like Full Mojo Rampage. Native games don't have that issue. The only other thing that gives coil whine is running Folding@Home on the GPU, which is nowhere near as loud as Proton.

Often games run through Proton will have distorted sound, like clipping but not. If I had to guess I'd say that it was being run at the wrong bit rate: the signal is there and there's also random noise. Weirdly, switching to a TTY and switching back again, with the game running, fixes it. Again, it's only Proton that does this, nothing native.

In case it's useful, I'm running Kubuntu 18.04, my GPU is an RTX 2080 Ti, and the sound is through a Focusrite Scarlett 212.

I'm just wondering whether anyone might know of something that I might have overlooked with either of these issues before I put in a bug report.

[thetargos]

The issue about fan noise with Proton (I bet it also happens with regular wine) is due to the overhead, and I am not sure it'd be the GPU necessarily which is the culprit for the fan noise (I am not familiar with your system's cooling, but it could also be the CPU/Case fans or even an AIO if you have that, plus in case of an AIO, the pump can also get loud as the circulation increases to appease the rising temps).

Both Proton and Wine will most likely peg your CPU (not necessarily the game thread, as such) in order to perform their magic so you can run Windows apps and games on your Ubuntu, and depending on the actual application, they could require more or less CPU juice.

Have you made sure which component is actually causing more sound (CPU/GPU/Case fans)? Testing with a sensors app such as Gkrellm or another could shed some light on the issue, and component which is causing the increase in sound.

Edit

Shoot! Totally forgot commenting on the sound issue.

As your own experience indicates it may boil down to a sound driver issue, rather than the sampling rate, which I'd assume is the right one, my guess would be in regards to the buffer, seems like a buffer underrun you are having (hearing), Just to be clear, the sound clears as you go to a TTY, do you log in in said TTY and then return or simply switching back without log in gets the sound "fixed"?

I ask, since as you go to the prompt, obviously sound stops (that's how Pulse Audio works), and as you get back and resume, PA handles the sound again. I would bet that if you log in to the TTY the same would happen, only you would hear that from the TTY, indeed seems to support my buffer underrun theory, here[wiki.archlinux.org], the almighty Arch Wiki article on PA may shed some light as to how to increase and test the buffer size and fragment size for PA.

[Cat on Linux]

if game pegs your CPU to 100% it can impact sound as well, it can became choppy.
also there's one trick to correct sound issue if it's software related

edit pulseaudio config and specify the following ---- in /etc/pulse/daemon.conf
default-sample-format = s24le
default-sample-rate = 41000

then run in terminal or append to game launcher
export PULSE_LATENCY_MSEC=60

[Aoi Blue]

Three things:

1. Overhead: Wine, used in Proton, will use more hardware power to do the same thing.

2. DXVK has greater Parallelism than D3D10/11: On low end games running on D3D10/11, Proton uses DXVK by default. This that while there is more overhead, your card, being plenty ample of running tasks in parallel, isn't going to be waiting around for another part of the scene. DXVK actually does this better than Windows, and is why it sometimes gets better framerates on high end systems that get bottlenecked, despite having higher overhead. Simply put, you might not be bottlenecked on the game. While this doesn't (yet) make up for the overhead, it certainly makes the overhead come out of the GPU's spare idle cycles instead of system limits.

3: Vsync and other forms of rate-limiting: This needs a whole big paragraph, so see below.

Linux drivers don't force vsync by default in low end games, nor do they downtrottle the card when hitting properly high way frame-rates the way Windows drivers do. Native games are written to properly handle this.

There are two ways other than vsync to throttle graphics:
1. Yield/Microsleep on end of frame or early frame. (Hands back control to the OS when done rendering a frame instead of going to the next frame, in case of microsleep cues that it doesn't want back control for a specified time)
2. Manual swaprate control. This works exactly like vsync except without waiting around for the sync to push the swap. It can also be done with V-Sync, especially if you want to do additional cascading back-buffers to smooth out stutter at the expense of a little latency.

[WarnerCK]

Originally posted by thetargos:

The issue about fan noise with Proton (I bet it also happens with regular wine) is due to the overhead, and I am not sure it'd be the GPU necessarily which is the culprit for the fan noise (I am not familiar with your system's cooling, but it could also be the CPU/Case fans or even an AIO if you have that, plus in case of an AIO, the pump can also get loud as the circulation increases to appease the rising temps).

It's not fan noise. It is coil whine.

I am very familiar with the sounds of each of my nine fans. It isn't them.

Coil whine is simply a high-pitched whine. It's generally caused by the components in power circuitry switching at high frequencies.

Both Proton and Wine will most likely peg your CPU (not necessarily the game thread, as such) in order to perform their magic so you can run Windows apps and games on your Ubuntu, and depending on the actual application, they could require more or less CPU juice.

The CPUs are not under heavier load running games through Proton than when running native games. It could well be a general Wine issue rather than the specific Proton implementation.

Have you made sure which component is actually causing more sound (CPU/GPU/Case fans)? Testing with a sensors app such as Gkrellm or another could shed some light on the issue, and component which is causing the increase in sound.

It's not the fans. The temps are not high (I habitually check temps with Conky). It is coil whine.

As your own experience indicates it may boil down to a sound driver issue, rather than the sampling rate, which I'd assume is the right one, my guess would be in regards to the buffer, seems like a buffer underrun you are having (hearing), Just to be clear, the sound clears as you go to a TTY, do you log in in said TTY and then return or simply switching back without log in gets the sound "fixed"?

It's not a driver issue. Sound is fine in everything but Proton, is often fine in Proton from the start, and can be made fine without any change in the driver. It is an audio stream issue.

Switching to the TTY causes the sound to stop, as you say. Either switching back from the TTY or logging into the TTY causes the sound to resume without issue.

I ask, since as you go to the prompt, obviously sound stops (that's how Pulse Audio works), and as you get back and resume, PA handles the sound again. I would bet that if you log in to the TTY the same would happen, only you would hear that from the TTY, indeed seems to support my buffer underrun theory, here[wiki.archlinux.org], the almighty Arch Wiki article on PA may shed some light as to how to increase and test the buffer size and fragment size for PA.

Buffer underruns sound significantly different. And, again, the CPU is not under heavy load, and the DAC is done by an external device.

Originally posted by Cat on Linux:

if game pegs your CPU to 100% it can impact sound as well, it can became choppy.
also there's one trick to correct sound issue if it's software related

edit pulseaudio config and specify the following ---- in /etc/pulse/daemon.conf
default-sample-format = s24le
default-sample-rate = 41000

then run in terminal or append to game launcher
export PULSE_LATENCY_MSEC=60

The CPU is a Ryzen 2700X. There are plenty of spare cycles. PulseAudio's default settings haven't made a difference previously, but when I get a chance I'll run things windowed so that I can check the properties of the sources and sinks.

Originally posted by Aoi Blue:

Three things:

1. Overhead: Wine, used in Proton, will use more hardware power to do the same thing.

2. DXVK has greater Parallelism than D3D10/11: On low end games running on D3D10/11, Proton uses DXVK by default. This that while there is more overhead, your card, being plenty ample of running tasks in parallel, isn't going to be waiting around for another part of the scene. DXVK actually does this better than Windows, and is why it sometimes gets better framerates on high end systems that get bottlenecked, despite having higher overhead. Simply put, you might not be bottlenecked on the game. While this doesn't (yet) make up for the overhead, it certainly makes the overhead come out of the GPU's spare idle cycles instead of system limits.

3: Vsync and other forms of rate-limiting: This needs a whole big paragraph, so see below.

Linux drivers don't force vsync by default in low end games, nor do they downtrottle the card when hitting properly high way frame-rates the way Windows drivers do. Native games are written to properly handle this.

There are two ways other than vsync to throttle graphics:
1. Yield/Microsleep on end of frame or early frame. (Hands back control to the OS when done rendering a frame instead of going to the next frame, in case of microsleep cues that it doesn't want back control for a specified time)
2. Manual swaprate control. This works exactly like vsync except without waiting around for the sync to push the swap. It can also be done with V-Sync, especially if you want to do additional cascading back-buffers to smooth out stutter at the expense of a little latency.

I always run VSync. Set in nvidia-settings and in-game. I really dislike tearing. My monitor only does 60 Hz: the reason I have a 2080 Ti is so that I'll essentially never drop below 60 fps, even with all the pretties. Again, it's not an issue with native Vulkan games, only those through Proton (and potentially vanilla Wine, which I haven't tested yet).

[Aoi Blue]

Do any of these games have options to force OpenGL or Vulkan?

That might give you better behavior.

There are also the issues of asynchronous buffer passes running at insane framerates even though they aren't displayed. These are things like your fancy lighting and such.

If the game is running Direct3D 9 it will use WineD3D instead of DXVK which will also mean using the ESYNC patch found in Proton Wine. This patch, contrary to it's name, provides more asynchronous behavior by providing signal-based selectively synchronous behavior. Since this results in some non-standard quirks. This is why the patch isn't in the Main Wine build yet and is a toggle in the wine-staging tree. One of the common misbehavior patterns is Buffers exceeding V-Sync rate (as well as Buffers tearing mid copy).

Considering your computer's capabilities, you could try the no-esync option. If you need help finding the Proton GitHUB page on how to do this, I can help you, but I'd rather you learn to help yourself once I point you in the right direction, as that helps you even more.

[WarnerCK]

Originally posted by Aoi Blue:

Do any of these games have options to force OpenGL or Vulkan?

That might give you better behavior.

There are also the issues of G-buffer passes running at insane framerates even though they aren't displayed. These are things like your lighting and such.

It would have to be a Proton option. As far as I know the games themselves don't have options for changing the rendering path, but I'll check. I'll play around with the Proton launch options to see if they help.

Vulkan should be the default for Proton, though, as far as I know, and that should be the best option. Having one thread running very fast - the OpenGL approach - would be more likely to cause coil whine than having many threads ticking along - the Vulkan approach.

Edit:

Considering your computer's capabilities, you could try the no-esync option. If you need help finding the Proton GitHUB page on how to do this, I can help you, but I'd rather you learn to help yourself once I point you in the right direction, as that helps you even more.

I'm not green: I've been using Linux for 14 years. It's specifically fresh pairs of eyes from people that are familiar with fiddling with Proton that I was after.

I'll try disabling esync as my first test when I get a chance.

[Aoi Blue]

Originally posted by WarnerCK:

I'm not green: I've been using Linux for 14 years. It's specifically fresh pairs of eyes from people that are familiar with fiddling with Proton that I was after.

I'll try disabling esync as my first test when I get a chance.

Good, than you understand why I didn't look up the exact parameter myself, but was nice and told you what to look for in exactly which manual instead of just RTFM.

I'm also very specific about why I'm doing it so other Linux techies learn the teaching method.

[thetargos]

It may be my hardware (or case for that matter) or simply my ears are not that good. I have not 'heard' the 'coil whine' you describe (as if the VRMs were maxed out, but that would mean the whole voltage and power draw of your system should go up with Proton, as anyone would expect). I have a first gen Ryzen 7 1800 and a GTX 1080.

It would really be interesting (if you have the time and interest, of course) to know if running plain wine causes the same.

[Aoi Blue]

Some fans make a very strong sound similar to coil wine.

The fan that ships with the Ryzen processors is almost indistinguishable from coil whine. It's a small fan so it's noise is high frequency.

I have never heard coil whine from modern computers. Of course, I buy high end power supplies for any performance computer, and sufficient case cooling.

The only place I have actually heard coil wine is from other devices.

[WarnerCK]

Fans and coil whine really don't sound similar at all. Unless your fans are running at 300,000 rpm.

It's pretty disappointing that you're both still trying to go PCMR and talk about fans and cooling. Coil whine is easy to understand, and there's plenty of information about it. It's a resonance thing, like a tuning fork.

Interestingly, the issues appear to be linked rather than two separate issues as I'd previously thought. I just ran Full Mojo Rampage and coincidentally didn't have the sound issue. I didn't have the coil whine, either. Something about the wrong stream being generated, or the brutality of the fix, appears to set up the coil whine.

[thetargos]

Originally posted by WarnerCK:

Fans and coil whine really don't sound similar at all. Unless your fans are running at 300,000 rpm.

It's pretty disappointing that you're both still trying to go PCMR and talk about fans and cooling. Coil whine is easy to understand, and there's plenty of information about it. It's a resonance thing, like a tuning fork.

Interestingly, the issues appear to be linked rather than two separate issues as I'd previously thought. I just ran Full Mojo Rampage and coincidentally didn't have the sound issue. I didn't have the coil whine, either. Something about the wrong stream being generated, or the brutality of the fix, appears to set up the coil whine.

OkI had to search a sound sample for that and now I know what you are getting (this). I did have that in some systems back in the 5000 NV series with a 5900. And I could hear it through the speakers (and headphones), as well (resulted an insulation from the onboard sound, solved with a dedicated PCI Audigy card). Alas, what I am able to find is this sound over the regular sounds of your system.

Unfortunately, apparently it is inherent to the power draw, and the only thing I can think of is either test with a different PSU, see if the PCIE power connectors may be at fault or replace the card (or test with a different one) if possible.

[WarnerCK]

The Witcher 3 through Proton seems to be playing a s32le/48000 stream regardless of what PulseAudio has actually provided. Setting the defaults to that means that The Witcher 3 has been starting with good audio.

In the couple of tests of it I had time for today, Full Mojo Rampage didn't start with the bad audio, so I haven't been able to get good testing there yet.

[WarnerCK]

Originally posted by thetargos:

Unfortunately, apparently it is inherent to the power draw, and the only thing I can think of is either test with a different PSU, see if the PCIE power connectors may be at fault or replace the card (or test with a different one) if possible.

It is generally power circuitry that has the issue, but it's not a function of power draw. It's the switching rate that's the critical issue for coil whine. One of the standard "solutions" is to increase the rate so that although it's still ringing away, it's doing so outside of the audible range.

Although the power circuits in my machine are of good quality (the VRMs on the motherboard and in the PSU), and are quite overprovisioned for the actual draw, coil whine isn't a sign of bad quality, particularly. It's just things lining up so that you get resonance. Well-engineered circuits and cheap circuits are both capable of exhibiting the behaviour, or of being fine.

Again, it's only been things through Proton (and some quiet whine when running Folding@Home) that have had the issue. Nothing native. Not even native things that are way more demanding than anything I've run through Proton.

[Aoi Blue]

Originally posted by WarnerCK:

Fans and coil whine really don't sound similar at all. Unless your fans are running at 300,000 rpm.

It's pretty disappointing that you're both still trying to go PCMR and talk about fans and cooling. Coil whine is easy to understand, and there's plenty of information about it. It's a resonance thing, like a tuning fork.

Interestingly, the issues appear to be linked rather than two separate issues as I'd previously thought. I just ran Full Mojo Rampage and coincidentally didn't have the sound issue. I didn't have the coil whine, either. Something about the wrong stream being generated, or the brutality of the fix, appears to set up the coil whine.

Quit presuming where I got my information and ask.

I am not some PCMR hobbyist. While I am quite skilled at such things, my training goes far beyond that.

I studied designing and building and have repaired electronics for more practical experience of what actually sounds like what. I am well familar with the sounds of various parts and what causes them.

Coil wine is caused by one of two thing: Heat cycle vibration, or core shift vibrations. Usually these resonate with the coil's or core's resonance frequencies and generate audable sideband tones between 500hz and 12,000hz.

The actual frequency of the power supply circuit is between 200,000hz and 300,000hz or primary frequency is not audible, although the coil vibrates at that frequency (and much louder), you can't hear it.

The induction method is heat vibration here, as well as magnetic vibration in the core.

Your explaining things in elementry school science terms either means that you do not understand that I have college level education in electronics, or you don't respect my intelligence. I'm respecting your intlelligence, please respect mine.

The resonance of fans I am talking about are bearings. These tend to resonate. The AMD Wraith Cooler fans use ball bearings, which while providing very low resistant, release almost all that resistance in audible range as vibration noise. This makes the fan louder than the

Your CPU fans spinning up is also a sign of system load. I just wanted to make sure you had right issue.

The following things make the same high pitched whine:
Chokes, Capacitors, Motor Coils, motor bearings, yoke coils, Vaccume tubes, crystal resonator, bad FETs, bad heat-sink binding (i.e. dried up heatsink paste.)

The folliwing of those things would actually be in a computer and be large enough to make a substantial whine:
Chokes, Capacitors, Bearings.

While FETs and heat sink binds are in a computer, it takes roughly 10-20 years, for them to break down to the point to make noise unless you are running current through them that you wouldn't find inside a computer, even with the insane power consumption of high end gears. (A bare minimum of a 200 watts over a single FET)

Typically the bearings on smaller fans between 2.5-4mm are the loudest. Don't ask me why,
If I wanted to reverse engineer why I could probably figure out, but it's not a big deal to me.

Most people think of fan noise as fan blade noise. This is a completely different sound.

Meanwhile, the chokes and capacitors are found on both your GPU's On-Board power supply, your CPU On-Board power supply or the VPU. This means high CPU usage can also make this noise.

As of FET noise, yes these power supplies have FETs but FETs only make this noise when they are highly overtaxed or worn out, which I would not consider likely.

[thetargos]

Originally posted by WarnerCK:

Again, it's only been things through Proton (and some quiet whine when running Folding@Home) that have had the issue. Nothing native. Not even native things that are way more demanding than anything I've run through Proton.

And that's what is extremely curious about your issue, since any software making use of the card should elicit it, as it is related at how the components behave for that particular card. Higher usage would suppose higher frequency of operation. I wonder, if your system has performance to spare, haow would it fare should you limit the frequency of the card from nvsettings or via powermizer. I would think it'd make little difference, but may be worth a try. Or overclock, as you said, to take the freq out of the audible spectrum (one subutilizes the card, the other induces wear).

Still, seems it results from how exactly Proton routes and uses the available resources of the card... it may be worth asking in the Level1Techs![level1techs.com] forums. I'm sure more than one hardware on Linux junkie will be quite interested in this issue with the 2080 Ti under Linux with Proton. Especially when the conditions for this seem so specific, and reproducible. Maybe someone else with similar hardware could also test and try to reach a solution.