steam-runtime
steam-runtime copied to clipboard
ValveSoftware
Upgrade OpenAL Soft to 1.19.1
OpenAL Soft 1.16 was released a couple weeks ago. Release announcement and notes:
http://openal.org/pipermail/openal/2014-August/000202.html http://kcat.strangesoft.net/openal.html
As far as I know, none of the updates are critical, but for example, XNA games that use FNA on Linux may require the AL_SOFT_block_alignment and AL_SOFT_MSADPCM extensions for SoundEffect and XACT support, so those games that wish to use the Steam runtime will need the latest version of OpenAL Soft. Other features such as the newly implemented EFX filters may also be required in the future as FNA's XACT support becomes more complete.
There are various other problems with OpenAL Soft in the Steam Runtime. Positional audio and surround sound is broken, and the resampling quality is terrible (all of this is very noticeable and affecting gameplay in e.g. Serious Sam 3). This is a configuration issue—Steam RT seems to outright ignore the system config for OpenAL Soft.
In general, it should be perfectly safe to update the OpenAL implementation, as the OpenAL specification requires ABI compatibility (which OpenAL Soft maintains).
I know, its an old bug and the OpenAL library wasn't updated, yet it could be since it doesn't break anything. It should be seen as safe to do. Maybe Steam should review some aspects of its policy about updating the runtime libraries.
Meanwhile, you can also set STEAM_RUNTIME=0 to use your system's libraries.
Wow, remember this old thing?
The runtime is now at 1.16, but since then a handful of releases have come out, and Proton (currently) uses an updated version:
https://github.com/ValveSoftware/Proton
If the Steam runtime's version was updated it would eliminate the need for this in Proton.
OpenAL Soft 1.20 has some useful changes in its pulseaudio backend. I'ld like to request it is updated to at least version 1.20.1, if it is to be provided at all.
If you have a newer version on your host, the library pinning logic should use that over the bundled version. Can you provide the relevant logs showing that this is not happening?
Sorry, I didn't realise it did that. It does appear to use the local version instead of the bundled one. I guess my issue is with distributions packaging OpenAL 1.19.1.
We're up to version 1.22.2 now.
It would be helpful to update it for those cases where you can't override the library yourself, like for example a Half-Life mod using OpenAL will use the runtime version because the Half-Life engine uses Miles Sound System which uses OpenAL internally.
The sniper runtime has 1.19.1 already, although I'll second the need for 1.22.2 because of its new Pipewire backend.
There are several runtimes with different properties.
The scout LD_LIBRARY_PATH runtime is used for most native Linux games on desktop (and for Proton 5.0 and older, but at this point I'd recommend using newer Proton versions instead). As Timo said, it has an ancient version of OpenAL (to go with its ancient versions of everything else), but if there is a newer version of OpenAL on the host system, it should automatically be used instead. So, if you would like to use a newer OpenAL with this runtime, please install it from your distribution. Note that if you are running a 32-bit game, for this to work, you will need to install a 32-bit OpenAL library: the 64-bit library is not enough. For example, you could install both libopenal1:amd64 and libopenal1:i386 on Debian/Ubuntu, or both openal and lib32-openal on Arch.
If you have a newer OpenAL library of the correct word size, but it is not being used by a game, then that means something has gone wrong with the intended shared library handling: if that happens, please open a separate issue with details so that we can investigate.
The "Steam Linux Runtime 1.0 (scout)" compatibility tool is used for most native Linux games on Steam Deck, and you can opt-in to using it on a per-game basis on desktop. It adds a scout compatibility layer to a Steam Runtime 2 'soldier' container, so it picks up the newer OpenAL Soft 1.19.1 library from soldier.
The "Steam Linux Runtime 2.0 (soldier)" compatibility tool is used as part of SLR 1.0 (scout), and for Proton 5.13, 6.3 and 7. Again, it already has OpenAL Soft 1.19.1. The latest client_beta version backports a change from newer OpenAL Soft versions to fix performance issues in GameMaker games.
The "Steam Linux Runtime 3.0 (sniper)" compatibility tool is used by a few early-adopter native Linux games (Battle for Wesnoth, Counter-Strike 2, Dota 2, Endless Sky, Retroarch), and for Proton 8. It has OpenAL Soft 1.19.1. The latest client_beta version has the same backported change as in soldier.
Every time we touch one of the older runtimes there's a risk of regressions, and upgrading a library is a one-way thing: after we have done it, we can't undo it, because new games might already be relying on API/ABI added by the newer version. So we are reluctant to do significant version upgrades, and that's particularly strong in very old runtimes like scout.
I did look into the possibility of backporting a whole new version of OpenAL into soldier and sniper instead of backporting individual changes, and it does compile successfully, but the benefit/risk trade-off didn't look favourable: the more changes we have, the higher the risk of breaking games that previously worked, which is absolutely not what we want. It is still an option, but if we are going to take that risk, then we'll need a better picture of what benefit we're getting from it.
If there are specific bugs that are a concern, another option is to backport specific bug-fixes into soldier and sniper's OpenAL, which would fix those bugs for Steam Deck and Proton 5.13+, and for games on desktop where you have opted in to Steam Linux Runtime 1.0 (scout). Depending on the size of the code changes involved, this might give us a better benefit/risk ratio than backporting the whole new upstream version: we would have to look at this on a case-by-case basis.
In general, it should be perfectly safe to update the OpenAL implementation, as the OpenAL specification requires ABI compatibility
That's the theory, but the difference between theory and practice is that in theory, there's no difference :-) If everything that aims to be perfectly backwards-compatible actually was perfectly backwards-compatible, there would be a lot less demand for stable/LTS OS distributions than there actually is.
the need for 1.22.2 because of its new Pipewire backend
If you're using Pipewire as your sound server, then using the PulseAudio "wire protocol" via the PulseAudio backend of something like SDL or OpenAL, together with pipewire-pulse running on the host system, is one of the recommended ways for audio to work: this is how most audio is handled on distributions like Fedora that were early adopters of Pipewire, on the desktop distribution I mainly use myself (Debian with GNOME), and on Steam Deck. Pipewire's audio implementation treats the PulseAudio protocol as a "first class citizen" that is fully-supported. This means that a "native" Pipewire backend for audio abstraction layers is much less important than it might seem at first glance.
The other side of this is that if an audio library mistakenly chooses to send audio to Pipewire, while running on an OS distribution where Pipewire is installed for use with video streams but is not acting as the sound server (for example a typical Debian 11 desktop, or a Debian 12 system that was installed with a non-GNOME desktop like KDE Plasma), then the failure mode is potentially very bad: audio streams go into Pipewire, Pipewire cannot open audio devices because PulseAudio is already using them, and no sound can be heard. We certainly don't want that!
