mirror of
https://github.com/games-on-whales/wolf.git
synced 2026-10-15 21:12:08 +00:00
[GH-ISSUE #374] Test audio works, app audio doesn't #253
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#253
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 @eco9898 on GitHub (Mar 28, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/374
I set up the container yesterday using the quickstart and I have not been able to get audio output. I have tried reading over other issues and applying changes, but most of what I have tried has resulted in no changes.
pactl list in prism container:
This is basically a default config but with paths modified for my steam apps and the wolf profile data to be in a different folder and audio is not working.
I am able to run and play minecraft well, and have had some issues with running proton builds of windows games through steam. I am hoping to test this out more once the audio issues are resolved but do not know where to go from here.
It may be relevant to note this is on a truenas scale installation as that is where my gpu is installed for transcoding purposes. This does mean that pactl is not found on the host, nor is alsamixer.
@eco9898 commented on GitHub (Mar 28, 2026):
I had hope #169 would help, but the timeout is not the issue as the pulseaudio container does start and connect to the wolf container before I connect via moonlight
@eco9898 commented on GitHub (Mar 28, 2026):
Sorry, forgot container logs:
wolf
pulseaudio
@ABeltramo commented on GitHub (Mar 28, 2026):
Wolf can't connect to PulseAudio, you can easily see that because of the second
After starting the container. Changing the env variable for the timeout usually helps in these cases, are you sure you've done that correctly? Which value have you set and how?
As for the PulseAudio container, do you see it up and running whilst Wolf is running or is it stopped? Have you tried force stopping the container, removing it and restart Wolf in order to force a recreation?
@eco9898 commented on GitHub (Mar 30, 2026):
I thought
[PULSE_ROUTER] Setup complete (handlers registered, PA subscribed)meant it was connected.I have set
WOLF_PULSE_CONTAINER_TIMEOUT_MSto10000for my wolf container. I can see this is set when looking at the environments values in the running container via a shell session.WolfPulseaudio container is starting and running. It has the above outputted logs and no further output.
I have tried removing the wolf and audio containers in different orders and recreating them without success. I'll try increasing the timeout.
@eco9898 commented on GitHub (Mar 30, 2026):
30 seconds looks to be working, no permission denied error logged.
Is there a value to stop the timeout. 0?
Would it be difficult to create a background process to hook in pulse audio once it is available, or does this need to be available at startup and will require Wolf to hang until the audio container is connected, like it currently will do.
@eco9898 commented on GitHub (Mar 30, 2026):
Wolf UI has sounds now, so that's good. To confirm steam and prism are routed correctly
@eco9898 commented on GitHub (Mar 30, 2026):
Audio seems good in apps. I assume isolation will work properly and no other issues other than disabling the timeout to ensure wolf will not start unless audio is available, or can hook into audio once it is available.
@evertonstz commented on GitHub (Apr 6, 2026):
This bug started happening to me after an update also.
@JBailes commented on GitHub (Jun 6, 2026):
@ABeltramo just a note from downstream: I had to increase
WOLF_PULSE_CONTAINER_TIMEOUT_MS(to 30000) in the unraid-plugin too to get a reliable audio sink on Unraid.@ABeltramo commented on GitHub (Jun 7, 2026):
This is something that we should probably revisit in Wolf and address once and for all. Setting it to
30000means that Wolf wouldn't connect to Pulse for 30 seconds. If a user starts a session before this deadline it'll result in no audio.This external pulse container it's a legacy leftover, and it has caused nothing but troubles. We should probably run PulseAudio directly inside the Wolf container and start Wolf once PA is up and running. Possibly using something like
supervisordto do it properly.@JBailes commented on GitHub (Jun 7, 2026):
You know what? I'm going to start working on that @ABeltramo , PulseAudio has been a pain in my ass in several development fronts and this would make it easier.
@ABeltramo commented on GitHub (Jun 7, 2026):
Ideally this should be just a change in the Dockerfile, no code needs to be changed. Wolf already checks if there's a PA server available on startup, and I'd like to keep the fallback to spin up a PA container. Thanks for looking into this!