mirror of
https://github.com/games-on-whales/wolf.git
synced 2026-10-15 21:12:08 +00:00
[GH-ISSUE #269] Audio of some games/apps goes to the wrong sink #187
Labels
No labels
🧠 1 - 🤖 999
AMD
bug
bug
cannot reproduce
documentation
duplicate
easy
enhancement
enhancement
enhancement
fixed?
fixed?
good first issue
hard
help wanted
Intel
invalid
LXC
medium
moonlight-protocol
Multi GPU
nixos
not a bug
nvidia
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
games-on-whales/wolf#187
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @AstronautMikeDexter on GitHub (Oct 13, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/269
When launching some games, notably, Victoria 3 and Minecraft, no game audio can be heard in the session in which they are launched.
Instead, the game audio is audible in the wolf-ui main menu.
Workarounds:
Please let me know if you need any more information. Thank you.
@Pizmovc commented on GitHub (Nov 17, 2025):
I'm having the same issue with the latest stable (with wolf-ui) and your second workaround works for me (I have not tried the first one).
I'm attaching the DEBUG logs for the following actions below:
wolf.log
My setup is documented in my blog post, but basically I'm using NixOS, where I manage wolf via systemd using a pre-start script to build the NVidia volume, stop any running wolf containers, etc.
Before updating to wolf-ui this issue only occurred occasionally, now it happens 100% of the time with Dwarf Fortress.
Interestingly, another game that I tried did not have this issue 🤷
@ABeltramo commented on GitHub (Nov 18, 2025):
After a bit of reading around, I feel that this might be tied to the fact that these games use OpenAL as the audio library.
You can easily control the behaviour of that library by creating a file in the home directory of the
retrouser called.alsoftrc. You can do that from inside the app whilst streaming with the terminal, viadocker exec -it -u retro <APP_CONTAINER_NAME> /bin/bashor externally by looking for the folder under/etc/wolfin your host (or where you've mounted that). I need your help guys (because I don't own either of those games) to experiment with this and to see what are the actual options that we need to set to make them work. Once we got something that works, we can easily bake that file in our GOW images.These are all the supported options alsoftrc.sample I'd start with something like:
and see if that changes anything.
In the meantime I'll see if I have any game in my library that uses OpenAL..
@Pizmovc commented on GitHub (Nov 18, 2025):
So I did a bit of digging and tried a few things.
pactl move-sink-input 39 9- moves the application to the other sinkShould Wolf automatically set container-specific sink as default on startup?
@ABeltramo commented on GitHub (Nov 18, 2025):
We already do that by setting the env variables
PULSE_SINK,PULSE_SOURCEandPULSE_SERVERto the right values for each running app. Well-behaving clients will pick those up and use the right virtual sink that we setup in Wolf.The fix that you are proposing will potentially break multi-user because when you do
you are actually setting the Pulse Audio server-side default sink.
We need a solution that is per-client, possibly something that we can set in the PA client settings
/etc/pulse/client.conf, maybe something likewould do the trick?
@sikkgit commented on GitHub (Nov 18, 2025):
I am encountering this same issue on every game launched by RPCS3 in Pegasus. I tried both workarounds and they work as described by @AstronautMikeDexter. I tried creating the
.alsoftrcfile as instructed by @ABeltramo but it didn't change anything.Edit: Unlike OP, I can't hear the game in the wolf-ui main menu.
@Pizmovc commented on GitHub (Nov 18, 2025):
Since the IDs are generated by Wolf, I don't know them beforehand, so I can't mount a file with correct IDs there to test.
And setting the config after container start does nothing, since presumably Steam/Pulse has already read it?
Any other ideas on how I could test this?
Another thing I noted, setting the default Output device in Steam settings to the Session ID sink makes the game sound work properly.
@ABeltramo commented on GitHub (Nov 18, 2025):
We set the env variable and you can pick that up before the app starts by adding a script under
/etc/cont-init.d/(ex: https://github.com/games-on-whales/gow/blob/master/images/base/build/overlay/etc/cont-init.d/10-setup_user.sh you'll have to manually add a mount point in yourconfig.toml) that creates the required pulse file.Something like:
I've tried a bit to replicate your issue but I can't trigger it on my side in Steam or Lutris for some reason. I'll try with RPCS3 as suggested above..
@Pizmovc commented on GitHub (Nov 18, 2025):
Ok, I mounted a script that created a file at
~/.config/pulse/client.conf.This was the
client.conffile after the script ran:Then I also tried setting the
/etc/pulse/client.conffile via the same script. In both cases I restarted the container.In both cases, Dwarf Fortress was outputting sound to the wrong sink and only setting the default sink with
pactl set-default-sink(before starting the game) or moving the input withpactl move-sink-input(after starting the game) works.As per https://linux.die.net/man/5/pulse-client.conf:
So it makes sense its not working. I guess the game gets the default sink in some other way.
For now, to avoid the manual intervention every time I start the container, I have modified the script to set the default sink on start-up and that fixes it for me. Since I'm the only user ATM, its working for me.
I'll try modifying it to periodically check for sources that are outputting into the wrong sink and move them automatically.
Which I think might actually be the only way to 'fix' misbehaving applications.
@ABeltramo commented on GitHub (Nov 18, 2025):
That's a shame and thanks for the link to the man page, at least I know that's not the right path to follow. I think that the apps affected are asking the Pulse server which sink to use and end up using the "global default". We could set that in Wolf via the Pulse socket but it would break multi-user.
Now I'm not sure if there's any way that we can fix that on the client side, but this caught my eye:
Can you check if that changes the default sink for PA like you were doing with pactl or is it some other trick? You should be able to check that with
The
*in front of the index indicates the current default input.@Pizmovc commented on GitHub (Nov 19, 2025):
Tried
pacmdfirst:But I think this should be the equivalent with
pactl:Here are some additional command outputs ran afterwards
Here are some command outputs with the game running
It looks like it does the same thing that I did with
pactl set-default-sink <sink>, withDefault (auto)being whatever the current default sink is.@ABeltramo commented on GitHub (Nov 19, 2025):
@Pizmovc thanks for all the info and for all the tests, that's really helpful. I'm not sure how to fix this without breaking multi-user, I have a few ideas but they feel quite complex..
@Pizmovc commented on GitHub (Nov 20, 2025):
I am glad I could help.
I don't see other options either. Perhaps a quick workaround, until a better solution is found, is a script that would scan for misbehaving apps and move them to the correct sink. I have created and tested it and its working fine for me.
Setup and monitoring scripts and mounting example
I had to mount the files of course:
Its important that you don't mount
wolf-pulse-monitor.shinto/etc/cont-init.d/since it will be run directly (not in the background) and will block the startup process of the container.@linxuhao commented on GitHub (Jan 5, 2026):
I got gemini pro implement a PID based watch dog script, works good with my 2 client test.
Below the code I added in /opt/gow/launch-comp.sh
then in
@camelcx commented on GitHub (Feb 2, 2026):
I was building a sober image and came across this problem. The watchdog solution above should work but I hate polling... So I found that we could use "pactl subscribe" to avoid polling. And we could just check the host instead of PID (move all input from matching host to $PULSE_SINK). I had the following script run in the background before the launch command in the startup-app.sh. This works for me. Again, if the game honours $PULSE_SINK, it would be much nicer...
@ABeltramo commented on GitHub (Feb 7, 2026):
This should be fixed now in the latest
wolf:stable, it would be nice if anyone from this thread can check the latest image out and report if it's correctly working for any of the app involved in this discussion.@linxuhao commented on GitHub (Feb 7, 2026):
I indeed see below new system in log, but I see all audio sinks are moved to one client, one client got "muted", the other display all sounds, exactly like when I force set default audio sink to the pulse audio server
@ABeltramo commented on GitHub (Feb 7, 2026):
Can you post the full logs? That doesn't really highlight any issue