Why is there persistent audio latency while streaming?

[dawuhe]

Persistent 350–450 ms Audio Latency with Windows 11 + Sunshine

Moonlight Version

• Moonlight Tizen: v1.16.0
• Commit: fecbc67
• Installation: Tizen WGT
• Audio backend tested: EMSS (default in v1.16.0)
• Audio jitter buffer: default setting

Device

• TV: Samsung QN85Q60CAFXZC / 85-inch Q60C
• Tizen OS: Tizen 9.0

Host

• OS: Windows 11
• CPU: AMD Ryzen 7 7840HS
• GPU: AMD Radeon 780M
• Host software: Sunshine
• Sunshine version: 2026.516.143833
• Sunshine audio capture: Windows audio output

Network

• PC and TV tested on the same 5 GHz Wi-Fi network
• Typical ping between PC and TV: approximately 1 ms
• Ethernet testing was also performed
• With both PC and TV connected by Ethernet, ping was <1 ms
• The audio delay remained approximately hundreds of milliseconds

Bug Description

There is a persistent approximately 350–450 ms audio delay when streaming Windows audio from Sunshine to Moonlight Tizen on this Samsung TV.

The delay is present even when the streamed display contains no video content relevant to the audio.

The laptop's local speaker and the TV speaker can reproduce the same audio simultaneously, making the delay directly audible.

Reproduction

1. Start Sunshine on the Windows 11 PC.
2. Connect the Samsung TV using Moonlight Tizen v1.16.0.
3. Use the TV as an extended or mirrored display.
4. Keep the Moonlight video stream active, but display an essentially empty desktop on the TV.
5. Play an MP3/music track on the Windows PC.
6. Listen simultaneously from the PC/laptop speaker and the Samsung TV speaker.
7. The TV audio is approximately 350–450 ms behind the PC audio.

The same behavior was observed with YouTube audio playing in the Brave browser while the TV was displaying only an empty desktop.

Important Observation: Delay Does Not Depend on Video Content

The delay occurs when:

• An MP3/music track is playing.
• Moonlight is continuously streaming an empty desktop.
• There is no video playback/application content on the streamed display.

The delay is therefore reproducible without requiring video frames corresponding to the audio.

This suggests that the problem can be investigated as an audio transport/decode/buffering/rendering latency issue rather than as a conventional audio/video synchronization problem.

Control Tests

Moonlight for Windows

Another Windows PC running Moonlight for Windows against the same Sunshine host did not show an obvious comparable audio delay.

Miracast

The same general PC/network/TV hardware was also tested using Windows Miracast.

A YouTube 25-second synchronization test played through Miracast showed the sound occurring essentially at the 0 ms point of the test scale, with no noticeable 350–450 ms delay.

This suggests that the TV hardware itself is capable of essentially synchronized audio playback.

Network

The problem remained with Ethernet connections and very low network latency.

Therefore ordinary network RTT does not appear sufficient to explain the approximately 350–450 ms delay.

Steam Streaming Speakers

Steam Streaming Speakers was installed and selected as the Sunshine audio endpoint.

The delay remained approximately 350–450 ms.

Therefore changing the Windows audio output endpoint from the normal Realtek speaker endpoint to Steam Streaming Speakers did not eliminate the delay.

Expected Behavior

Audio received by Moonlight Tizen should have low enough latency that it is reasonably synchronized with the same audio being played locally on the Windows host.

Other clients and Miracast on the same general hardware demonstrate that substantially lower latency is possible.

Actual Behavior

Moonlight Tizen consistently produces approximately 350–450 ms of additional audio latency under the conditions described above.

The delay is sufficiently large to be clearly audible when comparing the PC and TV speakers simultaneously.

Additional Information

The primary reproduction test is intentionally based on:

MP3/music playback + empty desktop streaming

This removes video content as a likely confounding factor while keeping the Moonlight streaming session continuously active.

I would appreciate any guidance on:

• expected audio buffering latency in the Tizen client;
• where the audio jitter buffer is implemented;
• expected RTP/Opus timestamp semantics in this path;
• EMSS audio buffering/scheduling behavior;
• whether similar 350–450 ms latency has been observed on other Tizen 9 Samsung models.

I can provide further controlled test results if useful.

[dawuhe]

Additional measurement results — separating Moonlight-Tizen processing from downstream TV audio latency

I performed additional instrumentation of the Moonlight-Tizen audio path to determine how much of the measured PC-speaker → TV-speaker delay occurs inside the Moonlight application itself.

The measurements were made using the same test environment described in the original post.

1. External measurement: PC speaker → TV speaker

I used an iPhone recording while the same short "ding" sound was played through:

• Windows PC/laptop speaker
• Samsung TV speaker receiving the audio through Moonlight-Tizen

Repeated measurements gave approximately:

• EMSS: ~382 ms average PC-speaker → TV-speaker delay
• Web Audio: ~526 ms average PC-speaker → TV-speaker delay

These measurements are substantially more repeatable than my earlier rough estimates.

2. Internal Moonlight-Tizen measurement

I then added instrumentation at several points in the Moonlight-Tizen audio pipeline:

• Point-A: immediately after the incoming UDP packet is received, before RTP/FEC processing and Opus decoding.
• Point-B: immediately after Opus decoding/PCM conversion.
• Point-C-EMSS: the downstream application boundary where Moonlight hands decoded audio to the Tizen audio/media subsystem when using EMSS.
• Point-C-WebAudio: the corresponding downstream application boundary when using Web Audio.

The measured Point-A → Point-C time was:

EMSS:

Point-A → Point-C-EMSS ≈ 5 ms

Web Audio:

Point-A → Point-C-WebAudio ≈ 112 ms

The EMSS measurement was observed over an extended run. Individual averages varied somewhat with time (for example, ~0.5 ms initially, ~7.4 ms after 10 minutes, and ~4.6 ms after 20 minutes), but remained very small compared with the approximately 382 ms externally measured delay.

3. Estimated latency outside the measured Moonlight-Tizen boundary

Using the corresponding measurements:

EMSS:

PC speaker → TV speaker       ≈ 382 ms
Point-A → Point-C-EMSS       ≈   5 ms
-----------------------------------------
outside measured boundary     ≈ 377 ms

Web Audio:

PC speaker → TV speaker       ≈ 526 ms
Point-A → Point-C-WebAudio    ≈ 112 ms
-----------------------------------------
outside measured boundary     ≈ 414 ms

Therefore, the unexplained portion is approximately:

(377 + 414) / 2 ≈ 395 ms

As a practical estimate, I currently consider ~400 ms to be the "elephant" — a large latency component that I have not yet been able to locate or measure inside the available Moonlight-Tizen application boundaries.

4. Current interpretation

The results suggest that the large delay is not primarily caused by Moonlight's EMSS buffering/scheduling path, since the measured Point-A → Point-C-EMSS processing time is only a few milliseconds.

The Web Audio renderer does add significant measurable latency (~112 ms), but this still leaves approximately 414 ms unexplained.

I also previously tested Windows Miracast on the same general PC/TV setup. Miracast showed essentially no noticeable PC-speaker → TV-speaker audio delay, although its video presentation has noticeably higher video latency.

A Windows Moonlight client connected to the same Sunshine host also did not show an obvious comparable audio delay.

At this point I therefore cannot conclusively determine whether the remaining ~400 ms is:

1. upstream of Point-A (Sunshine → Moonlight-Tizen ingress), or
2. downstream of Point-C (Tizen/Samsung media/audio subsystem → physical TV speaker).

The current measurements only establish that the large latency is not captured between Point-A and Point-C-EMSS when using EMSS.

I am posting these measurements mainly so that other users/developers can compare their results and potentially reproduce the same behavior on other Samsung/Tizen models.

[bigboo3000]

Hi I can confirm I have exactly the same issue with a TQ75QN90F, I don't have precise timing but there is a distinct sound lag between my laptop and my TV with the same stream on both, 300ms seems legit here.

[brightcraft]

Sorry for the late response. I was on vacation when this discussion was opened and haven't been available to properly look into it until now.

Thank you for the detailed report and the additional instrumentation. The measurements are useful, especially the very small Point-A → Point-C time measured with EMSS compared with the much larger externally measured PC-speaker → TV-speaker delay.

Some amount of latency between the host and client is expected. The PC will naturally produce the audio slightly earlier, while the TV still needs to receive, decode, buffer, process, and present the audio through its own media pipeline. On my Tizen 6.0 TV, this difference is barely noticeable during normal use.

What is particularly interesting here is that both affected reports are from newer Tizen versions: Tizen 9.0 in the original report and probably Tizen 10.0 in the additional report. Starting with Tizen 9.0, there have been platform-level changes and known streaming-related issues involving Game Mode on Samsung TVs, which can affect streaming behavior in ways that are outside of Moonlight's control. These limitations are documented in the Known Issues & Limitations wiki page.

The measurements also make it less likely that the large delay is being introduced by the EMSS processing path itself. A few milliseconds between receiving the audio and handing it to the Tizen audio subsystem cannot account for several hundred milliseconds of externally measured latency.

That said, the current measurements cannot conclusively determine where the remaining latency is introduced. It could involve processing or buffering before the measured application boundary, or the Tizen TV audio and presentation pipeline after Moonlight hands the audio off.

Before drawing a final conclusion, I would recommend trying different Moonlight streaming and audio settings to see whether the latency changes. In particular, please also try the experimental ForceGM variant if you have not already done so. This variant is intended for newer Tizen versions and may help determine whether the behavior changes.

If possible, comparing EMSS and Web Audio with different jitter-buffer and streaming settings, as well as testing the ForceGM variant, would provide useful additional information. If the delay remains consistently in the same range across these configurations, that would further support the possibility that the additional latency is coming from the Tizen platform rather than from Moonlight's audio processing.

[dawuhe]

Tried ForceGM variant v1.16.1, observed the same audio latency.

[brightcraft]

Thanks for testing the ForceGM variant. Since the same audio latency is still present, I would like to do one more comparison before drawing a conclusion.

Could you please install v1.15.0 and test the same scenario again? Since this version predates the introduction of the Web Audio backend, so the result should help determine whether the latency is related to the newer audio implementation or is present independently of it.

Please let me know whether you notice any difference in the audio latency compared to v1.16.1/ForceGM, and provide the results.

[dawuhe]

I tested v1.15.0 and https://github.com/ruanformigoni/moonlight-tizen v1.11.4 seperately before testing the combined version 1.16.0.
brightcraft v1.15.0 and ruanformigono v1.11.4 both show audio latency around 350-450 ms. When brigtcraft v1.16.0 became available, I am able to test both MESS and Web Audio through app ui configutation switching with one installation, and measured the audio latency (using kimi AI tool to analyse audio recording by iPhone) and posted the exact audio delay in my earlier post above.
In short, v1.15.0 shows the same audio delay.

[brightcraft]

Thanks for testing v1.15.0 as well.

Since the same audio latency is present in v1.15.0, which predates the introduction of the Web Audio backend, this further rules out the newer Web Audio implementation as the cause. Combined with the same behavior on both the standard and ForceGM variants of v1.16.1, there does not appear to be anything further to investigate in Moonlight's audio processing.

However, I cannot reproduce this behavior on my Tizen 6.0 TV. The issue therefore appears more likely to be related to changes or regressions in newer Tizen platform versions, particularly given that the reported case is on Tizen 9.0.

As a workaround, I recommend using a Virtual Display Driver together with Steam Streaming Speakers for streaming, rather than comparing the host's physical audio output with the TV audio simultaneously. This avoids the additional host-side audio path and is the setup intended for streaming.

Unfortunately, there is nothing further I can address from the Moonlight side, so I will close this discussion.