No audio in plain ALSA system (since last Steam update?) #707
Comments
|
Found out a little bit more. Under I worked around this by re-compiling the kernel with the loopback audio device no longer built-in. Now the audio device is detected as "Realtek Generic" and audio works in "Valheim" (yay) but not in "Old World" (aww). |
What do you mean by that, more specifically? A The recommended audio system for Steam on Linux is PulseAudio, or Pipewire with PulseAudio compatibility. Using an ALSA-only sound system, either directly to hardware or via dmix, is not really supported; sometimes it works anyway, but sometimes it does not (and the specifics do matter). Part of the problem is that ALSA means different things to different people: the same term "ALSA" describes a userspace-to-kernel interface, and also a userspace client library
If this is part of the root cause, that would indicate that there's potentially a problem with defaults and devices even outside the Steam Linux Runtime environment. In the past, The default device that is shown in that window is the one that Steam thinks is the default, and that doesn't necessarily match up with what each game is using. Do you have any more diagnostic information from Old World? |
|
Thanks for the detailed response!
I wasn't aware of ALSA dmix. Almost certainly
I was afraid of that. My experience with PulseAudio has always been:
While ALSA has always just worked... except when trying to capture, which, coincidentally, is the feature that was just added to Steam. I might give Pipewire with PulseAudio a try, though.
I doubt that as this set-up has been working for over a decade now. Though the ALSA docs aren't exactly comprehensible.
Nothing I can find in the UI. Using Looking at the mappings shows... everything mapped? I tried to investigate the container with I wonder why |
|
If I enter into the mount namespace of the process my EDIT: This would explain why "loopback" was being shown as the default device; before I disabled the kernel module the loopback card was number 0 and I had the default PCM and control card set to 1. I edited the file after disabling the kernel module. |
Tried this and now my system has no audio whatsoever. Will have to debug more later; need to sleep now. |
Right, that's a large part of why we generally recommend PulseAudio or Pipewire. The other reasons are that one of those is normally the default in a well-integrated distribution anyway, and with PulseAudio or Pipewire, the setup required to get audio across the container boundary simplifies down to making one You've said that you're using Gentoo, which in many ways is less like an OS distribution and more like a kit from which you can build a unique OS distribution of your own. Sorry, debugging the result of that is not something that we are really able to support.
Yes. Unfortunately, this is intentional: the host system and the container are using a different ALSA client library For configuration as simple as what you quoted: it would probably be sufficient to replicate it in
Perhaps. Because of kernel limitations on the way we create the container, we can only have one uid (yours) and one gid (your primary group) inside the container, with all other uids and all other gids mapped to the kernel's overflow uid/gid, which is typically nobody/nogroup. If this is a group access problem, it might work to set a POSIX ACL on the audio devices. On most systems, systemd-logind and udev work together to set this up automatically via the The ACLs that are normally set up by If your system doesn't do this automatically, you could try setting up something similar manually, and see whether that helps? Or, if this is a group access problem, it might work to ensure that Steam's primary gid is |
|
For what it is worth, indeed, for me Steam shows an actual hardware device (which is For example VVVVVV seems to use what I set in my configuration, while Amnesia: The Dark Descent grabs the hardware directly, meaning nothing else can use that device while it is running, unless something is already using the device before launching (maybe it tries the next device in line, and then uses my loopback device instead... it's not clear from the terminal output). I'm also running Gentoo Linux, plain ALSA with custom configuration (no PulseAudio or PipeWire installed), and no ACL support enabled and no systemd installed (but yes udev to some extent). (Interestingly, been a while since I've launched anything via Steam, and something seems to have changed so that it is messing with mouse pointer device sensitivity... possibly VVVVVV since there seems to be some new controller settings there, but that's a story for another place, and another time.) |
If they use
Yes, this is one of the major problems with using ALSA device nodes directly ( ALSA's
We cannot assume that all "plain ALSA" systems are the same, especially if there is custom configuration: the devil is in the details. Some use direct device access, some use dmix, in principle some could even be using a sound-server behind the scenes: the ALSA client library's plugin architecture means that in general, we cannot know what is happening. This means we cannot ever provide a one-size-fits-all solution to "plain ALSA", and we need to deal with each scenario individually. @clinew says they are not using |
The problem is that setting up PulseAudio and Pipewire is convoluted and incomprehensible for mere mortals. Though I actually got Pipewire working today after 3+ hours;
Understood. This is a problem I made for myself by using Gentoo, and I appreciate the detailed help you've given so far! I need to contribute some docs upstream, then I want to play around with my Pipewire config some more, then revert (taking careful note how to restore) and see if I can get ALSA working again. Basically, slim down until I can't slim down anymore. Will keep you posted and respond to your other suggestions as I go (it took ~4 hours to recompile for PulseAudio support, so I have to execute in serial), but it will likely take a few days as I slog through the work week. |
While this might have solved the issue with "loopback" being selected as the default, it wasn't enough to get audio working consistently across all games.
I did a hack test of this by giving the device files ownership of my user's group and it didn't help, but I didn't spend a lot of time since I don't think access is the issue; I was just having trouble getting into the container in order to debug. The following seems to work well:
One of the interesting things I found out while using Pipewire is that the Valheim's audio stream is identified as Unrelatedly, one interesting issue I ran into moving back from Pipewire to ALSA was that I was able to set the "default" card with: but audio formats were restricted to
One thing I noticed while trying to debug ( Though when I invoke OldWorld directly with When I invoke Valheim directly with this set-up, it crashes consistently after the splash screen; when I then invoke Valheim via Steam, it sometimes works. By "sometimes" I mean if I move my saved game data at
So it's very interesting how OldWorld fails but Valheim doesn't. I'd hypothesize thus: OldWorld (Wwise) has a hard requirement on PulseAudio APIs; this works with That being said, I can consistently play OldWorld by invoking it directly, and Valheim by launching it through Steam, and I'm okay to call that "good enough" for now. If you'd like to keep this open for tracking, or if there's anything you'd like me to test/provide info on that's fine, otherwise feel free to close the ticket, and thanks again for the support! |
This is not the same as having an ACL that gives access to your user by uid, and will not necessarily have the same results - although it seems that you have been able to get past any permissions issues that might have existed. To minimize divergence between what would happen on the systems with systemd-logind that are used by most Steam-on-Linux users, and what happens on your system, I would suggest setting up an ACL that is equivalent to the one that logind/udev would set up, which is something like this (untested): That should result in ACLs that are shown by The combination of systemd-logind and udev would normally set up an ACL like this on every device that has the udev tag |
Those presumably indicate the audio middleware libraries that are built in to in each of these games. FMOD is relatively common, so any workarounds that you might find for Valheim are likely to be applicable to other games. Wwise is less common, I think.
This is exactly the sort of thing I was concerned about when I said "ALSA means different things to different people". ALSA-the-kernel-interface and ALSA-the-user-space-library have very different scopes and interact with container technologies differently, but both are generally referred to as simply "ALSA", and users, developers and documentation often don't distinguish clearly between them. One of the properties of PulseAudio and Pipewire that is useful for the Steam Runtime is that they bypass the upper layers of the ALSA user-space library, and only use it as an API for lower-level interactions with the kernel interface, which cuts out a lot of the complexity of the ALSA user-space library and its plugin architecture.
This will most likely be because
I would be surprised if it's continually forking new processes (doing audio in a subprocess is not a programming model that I've encountered), but maybe it's continually starting new threads that try to connect to PulseAudio? And, yes, if that's what it's doing, it is correct that they try to connect to
Invoking Steam games directly (not via Steam, and not via the runtime library stacks that Steam provides) is not generally a supported use-case. It can sometimes work as a debugging step or as a workaround, but often will not, depending on the game and its needs. So we would not consider it to be inherently a bug if bypassing Steam and launching Valheim directly doesn't work.
I don't have specific information about the Wwise audio middleware, but that seems plausible to me. The vast majority of gaming-capable Linux systems provide the PulseAudio protocol on its
That also seems completely plausible to me. Audio middleware libraries often have a design with multiple backends and a graceful fallback between them in priority/preference order: SDL and OpenAL are prominent examples of open-source audio libraries with that design. (But, often the highest-priority/most-preferred backends are the only ones that get extensive real-world testing, so the lower-priority/less-preferred backends can easily regress without anyone really noticing.) |
By default, ALSA should use And yes, I use it in my custom configuration as well, along with some I do remember
In user-support related conversations, I can't remember encountering confusion regarding "plain ALSA", which I've always thought to mean just ALSA without PulseAudio and friends. It may include custom ALSA configuration files, or the defaults. In developer-support related conversations, I can imagine that being the case though, and will definitely keep it in mind going forward! :] And yes, ALSA can be a beast, and I definitely understand that not everyone will want to support a configuration without PulseAudio and friends. |
Your system information
Steam Beta Branch: Stable Client
Steam Version: 1730853027
Steam Client Build Date: Tue, Nov 5 1:33 PM UTC -08:00
Steam Web Build Date: Tue, Nov 5 4:21 PM UTC -08:00
Steam API Version: SteamClient021
Please describe your issue in as much detail as possible:
No audio in any games ("Old World" and "Valheim" tested).
System is plain ALSA (no PulseAudio, no Pipewire).
I ran into this issue late in the week and I did not make any changes or system updates between when I did not have this issue and when I first experienced this issue. Suspect issue triggered by a Steam update.
Audio is working fine in
mplayerandminetest, so audio equipment and system configuration is fine.I went into "Big Picture" mode and no audio device was detected (?!).
Steps for reproducing this issue:
I don't see any useful information in the client that can help me debug what audio device(s) Steam thinks exists and which ones it's using.
The text was updated successfully, but these errors were encountered: