The best thing to test here is probably this:įrom which you can run things like. Please could you capture a pressure-vessel and steam-runtime-system-info log without applying any special workarounds (and definitely not altering LD_LIBRARY_PATH), so that we have a baseline? The container setup is careful to select only the libraries that are required for the graphics stack, and are equal to or newer than the version in soldier it puts symbolic links to those libraries, and only those libraries, in /overrides/lib/* inside the container. This is done to make it more likely that a game that has passed QA testing on one Linux distribution will work on all Linux distributions.Īdding /run/host/usr/lib64 to your LD_LIBRARY_PATH inside the container is not how this is meant to work: that will result in us using all libraries from Slackware in preference to libraries from soldier, even if the Slackware libraries are older. We are not meant to be using libraries from your host system for audio (or networking, or compression, or really everything other than OpenGL/Vulkan hardware drivers). from Steam Runtime 2 'soldier', found in /usr/lib/x86_64-linux-gnu (which is SteamLinuxRuntime_soldier/var/soldier/files/lib/x86_64-linux-gnu outside the container). Inside the container, we are meant to be using the libSDL2-2.0.so.0, libpulse.so.0, etc.
VTRACE STEAM KEY GENERATOR DRIVER
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
VTRACE STEAM KEY GENERATOR CODE
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. 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: I think I got a little further with this. This makes me believe that the issue at hand is caused by the container environment. I 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. $ LD_LIBRARY_PATH=/path/to/Proton\ 5.13/dist/lib64:/run/host/usr/lib64:/run/host/usr/lib64/pulseaudio \įinished with 1219 successful tests and 0 failed tests # Test succeeding adding the libs under /usr/lib64/pulseaudio Test failed (/tmp/FAudio-20.11/tests/xaudio2.c:369): CreateMasteringVoice failed: 88960004 $ LD_LIBRARY_PATH=/path/to/Proton\ 5.13/dist/lib64:/run/host/usr/lib64 \ĪLSA lib pcm_dmix.c:1030:(snd_pcm_dmix_open) unable to open slave # Test failing and rolling back to ALSA without the libs under /usr/lib64/pulseaudio rwxr-xr-x 1 root root 55976 libpulsedsp.so* rwxr-xr-x 1 root root 758112 libpulsecore-9.0.so* rwxr-xr-x 1 root root 610504 libpulsecommon-9.0.so* The titles that are systematically affected on my system and that I've tested are: Game 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 strange thing is that the system is running on pulseaudio, so the ALSA error message seems a bit off.Īfter #343 got solved I'm also sure that the pulseaudio socket is now available inside the container runtime, but the issue still remains. INFO: OpenAudioDevice failed: ALSA: Couldn't open audio device: Device or resource busy
0 kommentar(er)
