smcv
commented
2 years ago If the dmix IPC protocol is long-term stable, it might be possible to set up pressure-vessel to share it across the container boundary. However, this would require someone who uses dmix to do the research to find out how it works, with a level of detail similar to what we already know about PulseAudio and Pipewire:
- which process or processes are responsible for actually opening
/dev/sndand outputting the mixed stream - what filesystem paths it uses to communicate
- what non-filesystem IPC mechanisms it uses, if any (POSIX semaphores? POSIX shared memory? abstract AF_UNIX sockets? other?)
- the specific names that it uses in those mechanisms
The pressure-vessel container runtime framework used for all Steam Linux Runtime compatibility tools does not support ALSA's "dmix" audio output multiplexing mechanism. I'm opening this issue to document this as a missing feature for which we do not need additional reports.
We recommend using PulseAudio or Pipewire for audio. Those services are not affected by this missing feature. When using PulseAudio or Pipewire, each program opens an inter-process communication (IPC) connection to the PulseAudio or Pipewire service, and uses that connection to send its audio stream; the service mixes the various streams, and sends a single mixed stream to the kernel via
/dev/snd. pressure-vessel is able to set up the container so that the PulseAudio and/or Pipewire sockets from the host system are available in the container, and their IPC protocols are long-term-stable, so it does not matter that the container's libraries and the host system's audio mixing service are different version numbers.The container runtime does not deliberately do anything to break "plain ALSA", but does not make any particular attempt to support it either. Because most Linux distributions use PulseAudio or Pipewire, "plain ALSA" is not treated as a high priority.
ALSA programs can be configured to output directly to audio hardware (each program talks to the kernel directly, via
/dev/snd), corresponding to device names likehw:0,0. This is not really supported by the container runtime, but as far as we know, it works. Most consumer audio hardware does not support mixing multiple output streams, so usually only one program can output like this at a time. (Some older separate sound cards like the Sound Blaster Live and Audigy ranges supported multi-channel hardware mixing, but typical on-board sound hardware on 2010s/2020s PCs does not.)ALSA programs can also be configured to output via the "dmix" user-space software mixer. This is a user-space component that receives multiple audio output streams from programs, mixes them, and sends a single stream to the kernel via
/dev/snd. This does not work in the container runtime, because it relies on all the programs that participate in "dmix" being able to communicate with each other, and running games in containers interferes with that communication.A basic requirement for carrying out IPC across the container boundary is that the IPC protocol needs to be long-term-stable, with feature discovery and backwards-compatibility across different versions of the implementation (because it is very likely that the library used inside the container is not the same version number as the service outside the container). This is true for PulseAudio and Pipewire. I don't know whether it is true for dmix or not. If not, then it will never be possible to support dmix. (A similar protocol incompatibility is the reason we cannot support JACK: #438.)
For completeness: dmix is for audio output (playback), but ALSA also has "dsnoop" to multiplex audio input (recording), and that presumably has the same issues as dmix.