what could cause scratchy audio on game mode?
The issue on github: https://github.com/ublue-os/bazzite/issues/435
GitHub
[Bug] Audio gets scratchy when loading into game mode with headphon...
The scratchy audio goes away when unplugging and plugging headphones back in
59 Replies
i have noticed this only happens if you go from gamemode to desktop mode and then back to game mode (also happens on a htpc with the deck image)
does it happen on steamos as well?
I’m curious, we’ve just been dealing with this on several distributions on the ROG Ally. If you leave the controls alone for 15 seconds after switching from desktop to game mode, does audio fix itself?
not on stock stable last time i checked, will check again as i am about to use my SD atm
audio is scratchy when you go from Game Mode to Desktop and back to Game Mode but it will clear itself if you leave it alone for 15 seconds after it launches. At least that’s the Ally behavior
gonna test it\
wait 15 seconds after the Steam logo with audio plays. If you navigate the UI before that point it basically starts another 15s countdown from my own testing
If that doesn’t fix it it’s probably separate issues then
doesnt happen on SteamOS 3.4.11 at least
I’ve only just noticed it in the past couple days. There’s a new BIOS out for ROG Ally which I thought was the cause of this, but if it’s happening on other devices that points to something like a Gamescope-session issue
gamescope did get some bugs yesterday-ish
it does fix
okay I’ll let the Gamescope-session devs know. thanks for checking that
I’m on Nobara which is a mutable Fedora distribution, going to try downgrading Gamescope-session and see what happens. I’ll report back if I find anything relevant to Bazzite as well.
what devices are you using? just trying to see if it’s only a certain manufacturer or hardware part
steam deck
a htpc i built long long long ago with an intel i5 4th gen cpu, 16gb ram and an rx560 8GB card (ends up with roughly the same performance as the deck on average but is a console and guest pc)
so 2 wildly different systems 😛
got it. do you know what audio chip is in there?
i will try to find out
thanks, much appreciated
Intel 8 series C220 according to lspci, however the audio chip being used is more likely the rx570 one as its over hdmi, that one would be Ellesmere HD Audio (no idea where to find the version for it)
got it. that should be enough info.
570, my bad its an rx570. doesnt matter though 🙃
just tested the 15 second thing, its the exact same sympthoms and fix
alright. ChimeraOS devs manage Gamescope-session so I put this in their discord and I’ll look at Gamescope later to see if any filed issues match this one.
Interestingly this isn't happening for me, but I'm on the Fedora 39 branch
Hopefully I'll have test images of that here soon
If it's as simple as that that's great news
I was talking to two people on the exact same setup as me (same bios version and kernel) and eventually their audio distortion magically disappeared. Mine hasn’t. Very strange stuff.
Yeah, lately when opening side menus a lot of times the audio get completely mangled timing wise. It's probably just game scope. Did anyone report this on the github repo already?
Oh, it's just with headphones audio connected? It's basically always for me lately.
it happens over Bluetooth as well apparently
Monitoring Steam, it seems that steamwebhelper is hammering one core after bootup for 15 seconds and if any input are applied it keeps hammering it.
If you wait, the load goes back down and no more audio stutters.
Yeah, matches my experience as well yesterday.
It might be a Steam beta bug.
I'll do additional testing now, I can easily reproduce with sleeping/wake up cycle.
(I'm on Deck, btw)
It's the whole system that's hitching, which made me think of some interrupts issues, but now I'm not that sure.
On Deck, the 6.5 kernel added an issue with the rtw88 driver that steals irq cycles after sleep when getting out from low power state, and I though that the two issues were linked toghether.
It doesn't seems that way now.
Nope, Steam settles down even with the audio issues.
Not sure at this point from where they are coming from
Can't really see any interrupts differences between stutter and no stutter.
Hardware are different, so no correlation with that.
It must be software somewhere.
I'll check 6.5.6 for audio changes
Can't really see other common sources for it
Opened a pipewire issue, it's the most probable cause.
Either pipewire or gamescope
since it's not affecting me on f39 anymore
I suspect pipewire
that build is feature complete if anyone wants to test it
just rebase to :39
Yeah, you might be right.
I'll try it then.
Can confirm that rebasing to 39 fixed the issue.
This definively points to a pipewire bug to me.
dope
Already fixed
GitLab
context: relax quantum change conditions (19b02003) · Commits · Pip...
We can change the quantum of a node while it is running just fine so relax the check. This was copied from the rate change logic, which is avoided while...
They work quick at pipewire XD
@KyleGospo
love it
Yep, just hoping that they'll release it soon.
Excellent news
I can try to build it locally and test it
nice, it’s getting added to Nobara today. thanks again for doing the legwork on this, glad it was a simple fix.
would’ve still been thinking this was a hardware issue unless I saw this thread
It was reported 6 hours before mine.
oh really? nice.
My report got literally closed when I posted it XD
They fixed like 20 minutes after XD
it was a pretty major regression, would’ve been noticed by more people very quickly.
GitLab
linux-integration 6.1.52-valve2 (1bd90d90) · Commits · evlaV / linu...
This release includes the following trees: 6.1/features/stable-updates: 59b13c2b647e464dd85622c89d7f16c15d681e96 ("Linux 6.1.52") 6.1/features/upstream: d6b36fa14b05526d537ed5ec237ecc077d4e2e27 ("drm/amd/display: ensure async flips are only accepted for fast updates") 6.1/features/amd-staging-drm-next: e786aef0869c711a70680d315ac2b838f03448ed ("...
not seeing that display patch here
very interesting
OOOOOO
That's impossible /s
either way that should have been upstreamed
so may just be fixed in the .6 release
You are right
There is not.
GitLab
hwmon: steamdeck-hwmon: Add support for max battery level/rate (6a4...
Add support for max battery level/charge rate attributes. Signed-off-by: Andrey Smirnov (cherry picked from commit 50af83e8fd75dc52221edd3fb6fd7a7f70c4d8a4) Signed-off-by: Cristian Ciocaltea
Interesting.
we have that one
I use it on my end, works great 🙂
Yeah, can't see it.
What the hell, Valve, where is your magic patch? /s
Unless some gpu related merges fixed it.
I doubt it tho.
I think a lot of them are just merging upstream stuff.
Wait, @KyleGospo
They haven't dropped sources yet.
That's the last branch update.
They haven't released the last week kernel update
That's why it's not there 😛
kid named gpl
Ssssh
They don't need to /s
reddit said so!
Like a lot of sources for their recovery system /doubles
I just check for the activity log in the homepage
It's easier
Thanks to that random dude that made this mirror.
At least.
for real
I can confirm that pipewire change does fix the issue 🎉
the reason you can wait 15 seconds after boot to restore good audio back is because gamescope goes into 0 fps mode, which makes the audio load properly. i noticed this because the time the blinking hover animation takes to stop animating is the exact amount of time you reported. you can make the audio load properly faster by using css loader plugin and disabling the blinking animation. probably wont matter on 39 tho
it’s already patched out in pipewire 👍
yeah already working on 39
Glad it's just not me
same