audio: make SDL queue threshold configurable

[popbones]

Summary

• add a user-configurable setting for Moonlight's pending SDL audio queue threshold
• keep the default threshold at 30 ms so existing behavior is unchanged unless the user opts in
• pass the configured threshold through to the SDL audio renderer instead of hardcoding it

Why

I was experimenting with higher values to reduce audio stuttering on my setup. Making the threshold configurable seemed preferable to changing the default for everyone.

Testing

• no clean upstream build/test run included with this branch on this machine
• feature change reviewed locally and kept narrowly scoped to settings/UI plus SDL audio threshold plumbing

Notes

For certain music like Cyberpunk 2077 title screen, the 30ms can cause the audio glitch very disorienting. For me, increasing it to 100 makes it unnoticeable for most of the time and only glitch a bit every now and then. See my comment in #1691

I got the idea when I had similar issues with chiaki-ng to play my PS5 games on SteamDeck. When in a bad spot, it may behave the same way. But Chiaki-ng has a setting to change something I assume do the same thing. And it worked for me.

[ns6089]

Audio crackling happens in two situations: buffer underrun and buffer overflow. So you need separate values for each of them: minimal buffer fullness at which playback gets started (either in the beginning or after buffer underrun), and maximum buffer size after which audio packets begin getting dropped. Then there's relative clock drift, but let's leave it aside for now as solving that properly requires moonlight protocol extension and realtime audio time-stretching DSP.

[popbones]

Thanks @ns6089

I’ve pushed some code and I hope it addresses your comment.

And here is a screenshot

I kept the default to effectively the current behavior since users should only need to tweak these when they have problems.

[ns6089]

How does it perform for you with 15ms playback and 30ms drop threshold? Those look like reasonable defaults to me, and may fix your problem without the need for the new GUI options. Since it's not a good idea to confuse the average user with advanced options placed right next to the basic ones, there's new Advanced config page in the planning, but unfortunately it's not ready yet.

[popbones]

How does it perform for you with 15ms playback and 30ms drop threshold? Those look like reasonable defaults to me, and may fix your problem without the need for the new GUI options. Since it's not a good idea to confuse the average user with advanced options placed right next to the basic ones, there's new Advanced config page in the planning, but unfortunately it's not ready yet.

For me, it's mainly the drop threshold, changing that to 100ms would make Cyberpunk 2077 title music work generally fine. I also tried 50ms and 70ms, but they seemed to be still too short. Changing the play side doesn't really affect my problem other than delaying the audio.

My suspicion is that some kind of jitter in Mac WiFi (probably related to AWDL, no proof though) caused the timing of audio to make tiny gaps in certain types of music or sound effects more noticeable.

My theory is that Moonlight receives bursty audio data that exceeds 30ms in durations longer than 30ms causing some data getting dropped.

This could cause the continuous undertone in Cyberpunk 2077 title music to sound like repeated onsets of the same sample instead of continuous ones. And this doesn't seem to happen on the iOS client in the same room.

Update:

I'm happy to wait for the advanced settings page while using my local build before it's ready. Just thought this might be helpful.

I see other people has similar problem and there didn't seem to be a definitive workaround yet. Myself has been having this problem over a year even after I upgraded my LAN network to latest generation. I guess for wireless network, there's always gonna be things like this.

It could be one of the first knob users can try if they have such issues. It's definitely more approachable than diving into network diagnostics and QoS.

[cgutman]

I don't think I want to make this a UI option (at least not yet), but I'm willing to accept a PR that uses environment variables to override the defaults if you'd like to go that direction in the near term.

[popbones]

@cgutman

I wonder if there’s other places than environment variables since it would be rather cumbersome to use on Mac. Do you think it would be possible to make the setting readable from the config file (com.moonlight-stream.Moonlight.plist) but not exposed in the UI?

[hamzah-hayat]

@popbones Just wanted to say thanks, I am running a Macbook air (M1) and was having severe audio stuttering issues when connecting to my main PC.
I compiled your branch and also set the SDL queue threshold to 100ms and it completely solved my audio stuttering
I'm so grateful, thanks so much ☺️

[popbones]

@popbones Just wanted to say thanks, I am running a Macbook air (M1) and was having severe audio stuttering issues when connecting to my main PC. I compiled your branch and also set the SDL queue threshold to 100ms and it completely solved my audio stuttering I'm so grateful, thanks so much ☺️

I'm glad it's helpful to you. 😊

[Meliods23]

@popbones

I love you my good sir, ran your changes after hamzah-hayat mentioned they worked for him and it solved my issue too on M4. I can finally enjoy frostpunk´s music. Thank you! :)

[Denisiso]

I compiled the Moonlight Client for MacOS with the changes from @popbones and no more audio crackling or stuttering when setting the value from 30ms to 100ms!

Thanks @popbones

[hugocowan]

Just going to say that I also pulled your branch and built it for an M4 mac, and setting the max queued audio to 100ms removed all audio stutter for me, even when the video was stuttering from having too high a bandwidth.

This effectively allows me to use a higher bandwidth for games I don't need perfect video for, as the audio was by far the most distracting problem in that situation. Thank you for your efforts popbones, I hope you come to an agreement with the maintainers on how to get this merged in.

[MaroonBrian1928]

Same, this finally makes Moonlight usable on Mac for me.

Github action to download build for anyone else who would like to use it. https://github.com/MaroonBrian1928/moonlight-qt/actions/runs/25618894698

[inf0cyte]

Pitching in here as well: popbones' changes allowed me to completely resolve audio popping on a macbook air m3 by setting sdl audio max to 100ms. No similar audio artifacting was present when streaming from the same host to a steam deck--this does seem to be an issue unique to macs.

[andygrundman]

Won't a high value like 100ms allow your audio to potentially be far behind the video, which in the best case might take only 1-2 frames to arrive. There's a bit of slack before your brain will notice something like that, but it seems like beyond 40ms you start to have a problem.

[MaroonBrian1928]

Won't a high value like 100ms allow your audio to potentially be far behind the video, which in the best case might take only 1-2 frames to arrive. There's a bit of slack before your brain will notice something like that, but it seems like beyond 40ms you start to have a problem.

The current situation is the audio completely dropping out several times a minute, which is much more distracting than it falling behind. Ideally, the underlying issue gets fixed, but with the current situation, the audio dropouts were so bad I had to stop using my Mac as a client, so this is a nice stopgap.

[popbones]

Won't a high value like 100ms allow your audio to potentially be far behind the video, which in the best case might take only 1-2 frames to arrive. There's a bit of slack before your brain will notice something like that, but it seems like beyond 40ms you start to have a problem.

Think it as a local playback buffer. It’s not the network is slow, but spiky. So imagine every 50ms, 50ms worth of audio data arrives. With a 30ms buffer that means, every time 20ms of data is discarded. And in many cases this is very audible. Making this buffer larger doesn’t necessarily mean the audio get delayed for that much, it just mean the audio will only be delayed that much if the data comes in.