414n
commented
3 years ago EDIT: turns out I was wrong. It seems like the pulseaudio detection code inside SDL2 fails to determine that pulseaudio is "alive and well" on the system and decides to switch to ALSA. This can be overcome by forcing the audio driver choice via the SDL_AUDIODRIVER=pulseaudio environment variable override or by making sure that the missing pulseaudio libraries (that live under /usr/lib64/pulseaudio on my system) can be found:
$ ls -l /usr/lib64/pulseaudio
total 1400
-rwxr-xr-x 1 root root 610504 Jun 22 2016 libpulsecommon-9.0.so*
-rwxr-xr-x 1 root root 758112 Jun 22 2016 libpulsecore-9.0.so*
-rwxr-xr-x 1 root root 55976 Jun 22 2016 libpulsedsp.so*
# Test failing and rolling back to ALSA without the libs under /usr/lib64/pulseaudio
$ LD_LIBRARY_PATH=/path/to/Proton\ 5.13/dist/lib64:/run/host/usr/lib64 \
./faudio_tests
ALSA lib pcm_dmix.c:1030:(snd_pcm_dmix_open) unable to open slave
INFO: OpenAudioDevice failed: ALSA: Couldn't open audio device: Device or resource busy
INFO: Assertion failed: 0 && "Failed to open audio device!"
test failed (/tmp/FAudio-20.11/tests/xaudio2.c:369): CreateMasteringVoice failed: 88960004
Segmentation fault
# Test succeeding adding the libs under /usr/lib64/pulseaudio
$ LD_LIBRARY_PATH=/path/to/Proton\ 5.13/dist/lib64:/run/host/usr/lib64:/run/host/usr/lib64/pulseaudio \
./faudio_tests
Finished with 1219 successful tests and 0 failed testsI also tested a game ("Assassin's Creed: Unity") outside Steam on regular wine (which was compiled on my system) and noticed no issues of the same sort, even if the game loads the xaudio2_7.dll. This makes me believe that the issue at hand is caused by the container environment.
ORIGINAL MESSAGE
I think I got a little further with this.
I can reproduce the same issue by launching the faudio_tests binary that is built along the FAudio library, both on my regular system and inside a pressure-vessel container:
$ LC_ALL=C \
LD_LIBRARY_PATH=/path/to/Proton\ 5.13/dist/lib64:/run/host/usr/lib64 \
./faudio_tests
ALSA lib pcm_dmix.c:1030:(snd_pcm_dmix_open) unable to open slave
INFO: OpenAudioDevice failed: ALSA: Couldn't open audio device: Device or resource busy
INFO: Assertion failed: 0 && "Failed to open audio device!"
test failed (/tmp/FAudio-20.11/tests/xaudio2.c:369): CreateMasteringVoice failed: 88960004
Segmentation faultThe audio initialization seems to fail because SDL2 chose an ALSA device instead of a PulseAudio one. By forcing the usage of PulseAudio over ALSA in SDL2 with the override SDL_AUDIODRIVER=pulseaudio i can overcome this issue, both in the test binary and in game:
$ SDL_AUDIODRIVER=pulseaudio \
LC_ALL=C \
LD_LIBRARY_PATH=/path/to/Proton\ 5.13/dist/lib64:/run/host/usr/lib64:/run/host/usr/lib64/pulseaudio \
./faudio_tests
Finished with 1179 successful tests and 0 failed tests.I'm a bit puzzled about this, however... Assuming that FAudio does nothing "exotic" when initializing audio devices via SDL2 and if SDL2 audio device detection on my system systematically fails to prefer PulseAudio over ALSA, I don't understand how this test program (taken from here, can be built with gcc test.c $(pkg-config sdl2 --cflags --libs) -o test) does always correctly detect (and prefer) the PulseAudio devices though:
#include <stdio.h>
#include <SDL2/SDL.h>
int main(int argc, char** argv) {
int i;
/* Initialize only SDL Audio on default device */
if (SDL_Init(SDL_INIT_AUDIO) < 0) return 1;
/* List Audio Drivers */
int audDvrCnt = SDL_GetNumAudioDrivers();
printf("SDL_GetNumAudioDrivers(): Found %d Audio Drivers:\n", audDvrCnt);
for (i=0; i<audDvrCnt; i++) printf(" Audio Driver %d: %s\n", i, SDL_GetAudioDriver(i));
/* Find Audio Output Devices*/
int audOutCnt = SDL_GetNumAudioDevices(0);
printf("SDL_GetNumAudioDevices(0): Found %d Audio Out Devices:\n", audOutCnt);
for (i=0; i<audOutCnt; i++) printf(" Audio device %d: %s\n", i, SDL_GetAudioDeviceName(i, 0));
/* Find Audio Input Devices*/
int audInCnt = SDL_GetNumAudioDevices(1);
printf("SDL_GetNumAudioDevices(1): Found %d Audio In Devices:\n", audInCnt);
for (i=0; i<audInCnt; i++) printf(" Audio device %d: %s\n", i, SDL_GetAudioDeviceName(i, 1));
return 0;
}
smcv
Your system information
Please describe your issue in as much detail as possible:
After selecting to run some games with Proton-5.13 or Proton-5.21-GE-1, these crash at different times after pushing "Play" in Steam, but all of them seem to crash shortly after an xaudio dll is loaded by wine. This is an excerpt of the trace from "The Witcher 3" (one of the affected titles) that can be seen from the Proton log:
The strange thing is that the system is running on pulseaudio, so the ALSA error message seems a bit off. After ValveSoftware/steam-runtime#343 got solved I'm also sure that the pulseaudio socket is now available inside the container runtime, but the issue still remains. I can usually work around this by making sure that no xaudio builtin dlls get loaded by wine: this makes the games not crash and audio works too.
The titles that are systematically affected on my system and that I've tested are: