Open colorzpe opened 1 year ago
AlbertBS45
commented
1 year ago I am also suffering this issue. With a fresh installation everything worked ok, but after some time the crackling began and uninstalling/installing again (v0.20) didn't solve anything.
The crackling audio still persists after changing the format to 16 or 24 bit 44.1khz.
I also tried different versions of Moonlight with no results.
Only thing that worked for me is downgrading to v0.19.1
BatJoe
commented
1 year ago I can confirm I have noticed this issue as well
huoyan1231
commented
1 year ago same here how to change the format to 44.1khz？
BatJoe
commented
1 year ago 
xCISACx
commented
12 months ago I have this issue too and downgrading did not help. I tried changing the format to 44.1 KHz and the audio stopped working until I restarted Sunshine. After I did, it still crackles.
snicmtl
commented
11 months ago Same issue on 0.2. Two Win10 machines on wired gigabit ethernet. Crackling in games and general streaming
JamTarty
commented
10 months ago Same issue for me too, I thought it was just user error at first. Wired connection, Win10 Cracking audio, when I switch to my wireless headset instead of the Steam streaming speakers the crackling goes away completely.
I've only tested this on my SteamDeck, but I assume it's the same on other devices based on the above.
LizardByte-bot
commented
7 months ago It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
alchist
commented
7 months ago I have same issue, tried to change audio quality, but no luck. Audio crackles once or twice a minute
1PercentSync
commented
6 months ago try latest nightly, mine works fine when switched to nightly
LizardByte-bot
commented
3 months ago It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
Anvil5465
commented
3 months ago This is a persistent issue for me
giejay
commented
3 months ago Someone recommended to change the wifi 5ghz channel to 44. That worked for me, I would say, give it a shot. This is his the video I'm using as a test: https://m.youtube.com/watch?v=WO2b03Zdu4Q
Anvil5465
commented
3 months ago Unfortunately, I have tried with both ethernet and wifi, so I don't think that is the issue for me
snicmtl
commented
3 months ago Has not been an issue for me in a while, win10 host client and wired
On Mon, Apr 8, 2024 at 14:15 GJ Compagner @.***> wrote:
Someone recommended to change the wifi 5ghz channel to 44. That worked for me, I would say, give it a shot. This is his the video I'm using as a test: https://m.youtube.com/watch?v=WO2b03Zdu4Q
— Reply to this email directly, view it on GitHub https://github.com/LizardByte/Sunshine/issues/1389#issuecomment-2043389743, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGIRUXCEPRRHJKPDYLD6EK3Y4LNFRAVCNFSM6AAAAAAZRCT5MGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGM4DSNZUGM . You are receiving this because you commented.Message ID: @.***>
f1yn
commented
3 months ago I know this is probably a stretch, but wanted to chime in as well. This is just a working theory at the moment:
Short: Try disconnecting your client device from said network for a minute (enough for a DHCP lease to revalidate, but at least long enough for said router to not think it's just a dropped connection). Then reconnect to said network. If that doesn't work, check if your router has any sort of QoS settings and maybe make sure that the packets to your remote client aren't getting needlessly deprioritized. For me, disconnecting and reconnecting a device from the network fixes all audio issues.
Longer:
A while ago, I was having some issues with my AMD card (7800 XT), and it ended up being an issue with the PCI slot. Moving it to a different slot seemed to clear up the choppy audio I was having over HDMI.
I've been using the Android client of Moonlight for some time, and recently I've noticed that after a few days, a specific device (but no other devices) would start to have choppy audio. There would be no error messages in Moonlight, or in Sunshine, but I'd get weird choppy audio that sounded more like the aforementioned AMD driver failure.
I tried all the other fixes, swapping Audio drivers, making sure I'm using a different bitrate for said driver. Manually overriding things. No changes, but still choppy audio. I also did a few hard reboots to rule out a driver state issue (which seems to be an AMD thing).
But then I took a chance. As far as I remember, higher bitrate medium going over any network uses UDP for the most part. UDP is a rapid fire protocol, it's up to the packets to figure out how to ensure "ordering" and when you're on a network that has more than one thing going on (swapping from wired to wireless, for example) there's a chance that those packets don't make it. That's where the term dropped packets comes from.
When I disconnected my Android client from the network for a minute, and reconnected to the existing Sunshine instance, there were no more choppy audio issues.
Why? Well, I think my ISP router was deprioritizing packets from the Sunshine host to the client. In more advanced routers (i.e not an ISP one), this is called QoS, and it makes sure certain types of traffic (usually from specific hosts) gets processed before any other traffic.
What seemed to be happening is that, the longer a client device is attached to the network, the more likely the router was to start lowering it's importance in terms of higher spread packet delivery. For TCP protocols (for which is used for the majority of non streaming web traffic), that's not usually an issue because it has a bunch of redundancies to make sure that retries can happen and that data can be validated in order. This isn't the case for UDP though, which is likely why the effects are so noticable and so jarring. Video data can sometimes work around this by stalling frames, but audio isn't so lucky. For codecs and implementations that attempt real time transfer, you're gonna get wicked clicks and audio artifacts due to it not being able to rely on past audio data the same way visual data can.
I need to emphasize though that this was entirely the fault of my router, so this might not be the cause of you already have a router that's not doing this. The catch is that I wasn't able to tell until I noticed an immediate change in result after reconnecting the client to the network.
This is just a hunch, but is honestly why this issue is so funky and hard to reliably reproduce.
Nitrousoxide
commented
1 month ago I am also still encountering this issue on my local network where latency and bandwidth should largely not be an issue. Jumping over to my host pc I don't hear the crackling through the speakers when it's streaming, just in the client devices.
beckman924
commented
2 weeks ago I´m having this issue too. Is there any fix?
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the nightly release?
Describe the Bug
Sound cracking / stutter on Streaming Speaker happen with default sound format (16bit 48khz)
can be solve by change format to 16 bit 44.1khz but need to apply every time when start sunshine
Expected Behavior
can i change default format ?
Additional Context
No response
Host Operating System
Windows
Operating System Version
10 21H2
Architecture
64 bit
Sunshine commit or version
0.20.0
Package
Windows - portable
GPU Type
AMD
GPU Model
rx 6600xt
GPU Driver/Mesa Version
22.11.2
Capture Method (Linux Only)
No response
Config
Apps
Relevant log output