Hello @TwoHandsWithoutThumbs, this issue should also be mentioned to the pipewire dev(s).
There seems to already be a thread for it over there. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3120 is most likely the same issue.
Not standard is to put it lightly. I'm not sure what you have done but surely that's not supported...
Your statement of having exposed the host pipewire-0 inside the container while running another PipeWire instance inside it does not make sense - there can be only one pipewire-0 socket, so the container's instance would need to create pipewire-1 (or another but always manually chosen name) and then everything needs to know which socket to pick. This is in theory doable but is pretty much developer level setup. And I'm not sure what the benefit is over just exposing the pipewire-0 and pulse/native sockets of your user within the container.
I'd suggest to not roll your own and instead use the Steam flatpak from Flathub which has this covered.
The PipeWire issue you found appears to be specific to high port count devices which are near exclusively used by professional musicians due to their size, cost and specific capabilities e.g. ingesting from many XLR microphones or instrument pickups simultaneously. There's a work-around inside the comments of the issue you linked but I doubt the very issue applies to your device.
Yep, you're right. I installed steam on my host machine and it worked fine, so it's an issue with either my setup, or podman-pipewire. Sorry for wasting your time.
TLDR for people with pro audio sound cards who want to play some games:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3120#note_2046068
proton experimentalx1 2023-06
I am running the 6.3.5-zen1-1-zen kernel on Arch, and I run steam in an arch-container under podman 4.5.1-1. I have pipewire and pipewire-pulse are at the latest version 1:0.3.71-2. I am running Proton Experimental and I've tried both 7 and 8.
Both my container and my host system run their own pipewire-server and the host pipewire socket is exposed to the container.
Audio works perfectly fine when neither of the sources are Proton. Audio from the container can mix with audio from the host, and audio from the container can mix with other audio from the same container, there is no issue there. I can run games under Wine (using the winealsa.drv driver) while watching youtube on Firefox (using the pulse-rust backend), but if one of the audio sources comes from proton, only the first program to connect to the socket will be able to use it. Under the helvium patch-bay, every audio source from the container shows up as an ALSA Playback [process name], but for games under Proton there is no entry at all.
At first I thought it was a container issue since that's obviously non-standard, but since everything else works it seems to be an issue with Proton. Do Proton use something other for audio than what's default for Wine? If so, what is it?