-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System-wide alsa config not considered in Steam Linux Runtime - Soldier #344
Comments
Hello @UFeindschiff, starting with Proton 5.13, Proton is run inside the Steam Linux Runtime - Soldier container environment and that is setup by Pressure Vessel. Let's treat this as a Pressure Vessel issue until there's a stronger indication the issue is elsewhere. |
Thanks for that pointer. That way I was able to investigate the prioblem further. Turns out Pressure Vessel does not respect the host's audio configuration. In my case I have my default PCM device set as device 1 (as device 0 is my GPU). This resulted in every application running through Pressure Vessel to attempt to create an output stream on device 0 and failing. Creating a link to /etc/asound.conf in ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/soldier/files/etc successfully worked around the issue. Maybe consider shipping such a link or have some pre-launch script which checks if /etc/asound.conf exists and creates a symlink if it doesn't |
We're basically in the same situation as Flatpak here: the main thing that is tested is PulseAudio. Direct access to the raw ALSA devices will often work too (we provide the equivalent of The major problem with importing
If you mean a symbolic link, I'm surprised - that shouldn't have worked. The |
You are of course correct. Looks like I just was too tired when creating the link and ommitted the -s by accident, therefore accidentally creating a hardlink. Sorry for the confusion.
Maybe then have Steam properly detect ALSA cards again (it used to years ago, where I could select different audio input and output deviced on different ALSA cards in the old Steam audio settings, these days I only have the single option "default") and generating an asound.conf to set the proper device as the default device in the container based on the Steam settings? I realize that there's likely someone else responsible for the development of the Steam Client and therefore this solution likely is only feasable in theory, but the status quo is bad as well. (as people will likely just wonder why there is no sound when playing their Windows games through Proton and think it is a poor experience) |
Gentoo without pulseaudio.
Sound is output through HD-Audio Generic
After proton 5.13 (pressure vessel), the sound disappeared, but on the advice of @UFeindschiff, the problem was solved: |
An update from what to what? If it's an update of
To be clear, this was always a workaround, not a solution. We don't have a complete solution for this: importing
Direct use of ALSA is not really something that we can put a lot of effort into supporting. Most OS distributions use PulseAudio (or sometimes Pipewire these days) for its ability to mix multiple audio streams, talk to Bluetooth audio devices and so on. You are of course welcome to configure your system however you want, but if you choose to configure it in a way that doesn't match Steam's assumptions, then part or all of Steam isn't going to work. Direct ALSA is also not something that we are actively trying to break, and if this regressed when upgrading from soldier version 0.20210309.0 to version 0.20210317.0, then I think I might see why this has happened now. If you switch to the previous_release branch of Steam Linux Runtime - soldier, attempt to run a game (to get the runtime files unpacked), and then reapply your workaround, does audio come back? |
Another thing you could (both) try is to put
into |
Can confirm. Today's update to the Soldier runtime broke it.
Yes, which is what I'm using as my temporary workaround, so it is definetely a regression introduced by the latest update.
You can do the same with plain ALSA, but I get where you're coming from as Pulse has graphical tools to easily do the most common setup changes there which is far more accessible for the average user. The only proper "advantage" PuleAudio has is that it is a proper sound server with networking support, so it can talk to remote audio devices (both input and output) which of course also comes with its own issues. |
both workarounds not working
workaround with files/etc/asound.conf working workaround with cat ~/.asoundrc
also working |
Thanks, this is exactly the sort of information I need. The next beta (pressure-vessel 0.20210414.0 or later) should hopefully fix the regression. |
The regression reported in #344 (comment) is now tracked separately, as #395. Please use #395 to represent the regression, and only respond to #344 for the original issue reported by @UFeindschiff. |
Since pressure-vessel 0.20210415.0+srt1 the user's ALSA config (~/.asoundrc) seems to be considered. Permanent workaround for the issue would be to copy your /etc/asound.conf to ~/.asoundrc. Thanks @smcv for the heads-up. |
Why even steam runtime override alsa/jack libraries? It always break all my configurations |
Hey @smcv, thank you for working with the folks who use ALSA-only systems. Pulse is obviously the dominant way these days, but there are plenty of us who avoid it because we legitimately need to. I appreciate your efforts to avoid breaking working systems. (I have high hopes for PipeWire, once it matures and proves itself.) |
Hi. I want to point out one detail that I consider important. This is for a workaround with ~/.asoundrc.
not works, but this
work well on the my system. I'm not sure if this is just my system. So if the first option does not work for you, then try the second. |
I can't get steam to try to use anything except the first alsa card (which is not the default) That's my video card and I don't have sound on my monitor. Support tells me there is no solution and maybe I should stop using steam. |
Mixing the old libraries in Steam Runtime and the new libraries on your actual computer is liable to cause issues. Perhaps a long-term option would be to route audio through something running outside of Steam Runtime |
That's exactly what PulseAudio or Pipewire do for us, which is why those work more reliably with containers (both the Steam Linux Runtime and Flatpak) than "plain ALSA". Presumably people on this issue are avoiding PulseAudio because of its (perceived or real) bugs, unreliability, performance limitations or size. Asking Valve to implement their own sound server as a workaround for the absence of PulseAudio seems unlikely to score any better on those metrics than PulseAudio does: once you start routing audio out of the container to a centralized sound server on the host system, you've effectively reinvented PulseAudio, but without the benefit of all the work that people have already put into it. If Pipewire is used for audio, it's effectively a replacement for PulseAudio. The accompanying
If you're running in a container (like the Steam Linux Runtime or Flatpak), then the audio devices on the host system have more in common with remote audio devices than you might expect. |
The container itself doesn't makes any troubles, e.g. these two options are enough to make even custom ALSA setup work in docker
|
Provider system integrators could redefine the alsa canonical default to the alsalib PCM plugin of the software mixer their choice in /etc/asound.conf (but the provider system integrators could choose to do that per user too, in $HOME/.asoundrc). [jack/pulseaudio2(pipewire/gwireplumber)/pulseaudio1/etc] |
Proton 5.13 (5.13-4 at the time of writing) and Proton Experimental fail to playback audio through ALSA.
Audio playback through ALSA works fine in Proton 5.0 and earlier, so this is a regression introduced with Proton 5.13.
Audio playback through PulseAudio is not affected and continues to work
Steps to reproduce:
The text was updated successfully, but these errors were encountered: