steam-runtime
steam-runtime copied to clipboard
ValveSoftware
System-wide alsa config not considered in Steam Linux Runtime - Soldier
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:
- Make sure PulseAudio is not installed or not running on your system (as otherwise Proton will playback audio through pulse)
- Make sure your default ALSA playback device is set up properly
- Force a game to launch through Proton 5.13 or Proton Experimental
- Listen to the silence
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 flatpak run --device=all), but isn't really tested or something that can be guaranteed.
The major problem with importing /etc/asound.conf from the host system is that we have no way to know whether the /etc/asound.conf from the host system is going to be compatible with the libasound.so.2 in the container. We could solve problems like yours by importing it, but we could equally be breaking someone else's system.
Creating a link to /etc/asound.conf in ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/soldier/files/etc successfully worked around the issue
If you mean a symbolic link, I'm surprised - that shouldn't have worked. The /etc in the container is populated from files/etc, so you would have had a recursive symbolic link /etc/asound.conf -> asound.conf.
If you mean a symbolic link, I'm surprised - that shouldn't have worked.
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.
The major problem with importing /etc/asound.conf from the host system is that we have no way to know whether the /etc/asound.conf from the host system is going to be compatible with the libasound.so.2 in the container.
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.
cat / proc / asound / maps
0 [NVidia]: HDA-Intel - HDA NVidia
HDA NVidia at 0xf7080000 irq 85
1 [Generic]: HDA-Intel - HD-Audio Generic
HD-Audio Generic on 0xf7700000 irq 87
Sound is output through HD-Audio Generic
cat /etc/asound.conf
defaults.pcm.card 1
defaults.ctl.card 1
After proton 5.13 (pressure vessel), the sound disappeared, but on the advice of @UFeindschiff, the problem was solved:
cp /etc/asound.conf {path}/SteamLinuxRuntime_soldier/{path}/etc/
Everything worked until today's update . How can now specify that the main card is # 1?
Everything worked until today's update
An update from what to what? If it's an update of SteamLinuxRuntime_soldier, please check SteamLinuxRuntime_soldier/VERSIONS.txt.
cp /etc/asound.conf {path}/SteamLinuxRuntime_soldier/{path}/etc/
To be clear, this was always a workaround, not a solution. We don't have a complete solution for this: importing /etc/asound.conf into the container as-is might be fixing it for you, but it also risks breaking audio for other people.
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
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
defaults.pcm.!card 1
defaults.ctl.!card 1
into ~/.asoundrc.
Everything worked until today's update
Can confirm. Today's update to the Soldier runtime broke it.
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?
Yes, which is what I'm using as my temporary workaround, so it is definetely a regression introduced by the latest update.
ability to mix multiple audio streams, talk to Bluetooth audio devices and so on
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.
- cat SteamLinuxRuntime_soldier/VERSIONS.txt
#Name Version Runtime Runtime_Version Comment
SteamLinuxRuntime v0.20210309.0-4-ge09b2e6 # Entry point scripts, etc.
pressure-vessel 0.20210317.0+srt1 scout 0.20210317.0 # pressure-vessel-bin.tar.gz
soldier 0.20210317.0 soldier 0.20210317.0 # com.valvesoftware.SteamRuntime.Platform-amd64,i386-soldier-runtime.tar.gz
both workarounds not working
- cat SteamLinuxRuntime_soldier/VERSIONS.txt
#Name Version Runtime Runtime_Version Comment
SteamLinuxRuntime v0.20210309.0-0-gb38a1fb # Entry point scripts, etc.
pressure-vessel 0.20210305.0+srt1 scout 0.20210309.0 # pressure-vessel-bin.tar.gz
soldier 0.20210309.0 soldier 0.20210309.0 # com.valvesoftware.SteamRuntime.Platform-amd64,i386-soldier-runtime.tar.gz
workaround with files/etc/asound.conf working
workaround with cat ~/.asoundrc
defaults.pcm.!card 1
defaults.ctl.!card 1
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 https://github.com/ValveSoftware/steam-runtime/issues/344#issuecomment-818894566 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. This
defaults.pcm.!card 1
defaults.ctl.!card 1
not works, but this
defaults.pcm.card 1
defaults.ctl.card 1
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.
Why even steam runtime override alsa/jack libraries? It always break all my configurations
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
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 pipewire-pulse service gives it the ability to speak the PulseAudio socket protocol, meaning it can take advantage of the client library code that has already been written for PulseAudio and reinvent as few wheels as possible.
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
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 --device /dev/snd -v $HOME/.asoundrc:/etc/asound.conf:
docker run -i -t --rm --device /dev/snd -v $HOME/.asoundrc:/etc/asound.conf alpine sh -c 'apk add alsa-utils && speaker-test -t wav -l 1 -c 2'
More details in https://github.com/mviereck/x11docker/wiki/Container-sound:-ALSA-or-Pulseaudio#alsa
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]
