The test buton in the sound settings is very helpful.
We all know that pipewire (or wireplumber) has some wake up time after being suspended. The test sounds are reasonably short. Sound migst seem broken as when clicking a speaker to test the sound nothing might be heard as pipewire needs time to wake up.
I see a couple of solutions
as the user probably wants to test after making a change pre-wakeup pipewire
enter a short delay to the test sounds to make sure that when sounds plays it can actually be heard
make the user aware of the problem or even give some visual indication that pipewire ist suspended.
i would be against any kind for automatic delay as it would make the UX frustrating when you click on something and nothing happens.
better would be for wire_______ and co to figure out their issues and for them to work as they are expected to workā¦ if that means checking in with each other to make sure sound is actually going out, than thatās what they need to do.
Not a (universally) True statement: noticing the time it takes for Pipewire/wireplumber to āwake upā after suspend is not a universal experience, most people donāt notice any delay at all - so the āissueā is likely due to your situation, not inherent.
Additionally, you state that (as you stated in your āSolutionā ) you are deliberately trying to click the ātestā button immediately on resume āas the user probably wants to test after making a change pre-wakeup pipewireā.
Well no, if YOU are making changes to your pre-wakeup pipewire, then you are definitely an edge case, not covered by the guarantee.
Notably:
Everyone knows that suspend is fast, but I would suspect most folks know it is not āinstantaneousā and that there is likely a very slight (almost imperceptable) delayā¦ for example, after suspending, I must wait a short while before hearing a āclickā (likely the PSU coming fully online) and seeing video as the screen wakes upā¦ I do also hear (as I have an external amplifier) a slight ābumpā in the speakers.
My experience is that I actually hear the audio come online before my screen wakes up (HDTV over HDMI)ā¦
However, the ultimate solution is simply to give your machine a second to wake up, not to build in extra delays (which themselves cannot be activated on a suspended machine, they would simply make it longer for the machine to resume).
Also, the statement āas the user probably wants to test after making a change pre-wakeup pipewireā is rather confusing in itselfā¦ you changed something in pipewire, then you need to suspend and resume, and immediately test it on resume?
Why?
If youāre testing balancing power saving settings with a fast reliable wake-up or something like thatā¦ well then the failure for sound to emerge immediately on clicking is all the information you need.
More to the point - what is the actual problem here?
I find the solution rather telling:
`Solution 1: as the user probably wants to test after making a change pre-wakeup pipewireā.
Well, thatās not a solution - and if thatās the issue, then the solution is extremely simpleā¦ be aware that resuming from suspend is not likely to be completed in less than a few hundred milliseconds - to expect this is unreasonable.
Iām hapily using my computer and donāt need sound for a while.
Now I want sound and I want to check if my speakers are on or my headphones or my AVR
I go to Settings sound and click test and click one of the speakers
I hear nothing. What could be wrongā
What actualy happend is that PIpewire went to sleep and didnĀ“t wake up in time to play a sound. WIth no visible clue. Yes I know I can click again and it probably will play a sound. But I will be already on hand and knees to check if the cat has again dislodged the cables.
The solution: Visiable clue, wake up pipewire before I even had a chance to test or a smal hint that sound might not play immediately. Or all of the above.
from this view i know the sound will be coming from the speakers, but if the middle item was selected i would know it will be going to my headphones plugged into the front panel.
Ah, ok - I was thinking about suspending the machine, not the audio suspendingā¦ thatās why I was talking about resume from suspend.
The fix for your issue is to change, or disable, the WirePlumber configuration to adjust the āsuspendā timeout. If you adjust to zero, then it disables suspend entirely.
You need to edit the WirePlumber Lua configuration file - and it is better to edit a copy in your own configuration directory so that updates will not overwrite any changes.
First, copy the following instructions and save them to a markdown file for later reference:
kate ~/.config/wireplumber/main.lua.d/50-alsa-config.lua
Setting 0 disables the timeout. Setting ["node.pause-on-idle"] to false can also help with resume delays according to a post I found on Lemmy: https://old.lemmy.ca/post/34443128
When youāre ready, you can restart:
systemctl --user restart pipewire wireplumber
You could also log out, or go the whole hog and reboot.
Iāve been using distros with PipeWire for years and I donāt think Iāve ever encountered this. Is it the result of some kind of power saving tweak you or your distro has applied?
I think you need to dig into the issue and its root cause first.
