Frequent "long rtt sync" warnings on grouped WiiM devices in Roon (ref#JKM030)

Support
1

What best describes your playback issue?

· Music stops playing unexpectedly

What type of Zone is affected by this problem?

· *Network Zones* are affected.

Is the affected network Zone connected with Ethernet or WiFi?

· WiFi

Does the issue affect all file formats?

· The issue affects *multiple/all* file formats.

Does the issue happen with local library music, streaming service music, or both?

· *Both streaming and local* *library* music are affected.

Do you encounter any playback errors with the "System Output" Zone?

· The System Output has the same problem as my other Zone.

Do you have a complex network setup?

· Both the device and RoonServer are connecting to a *single router*

Please try rebooting your router.

· No, I'm still having trouble

Do you have an approximate timestamp of when the issue last occurred?

· See time stamp in the example given in the description of the issue.

What are the make and model of the affected audio device(s) and the connection type?

· WiiM Pro and WiiM Sound

Describe the issue

Wanted to add a data point to the pattern described in the WiiM Ultra grouping/dropout thread (ref#R99NL4) — looks like the same class of issue on different WiiM hardware.

Setup: WiiM Pro (optical out to a receiver) and WiiM Sound, both on a UniFi wifi network, each pinned to separate APs on separate 5GHz channels (confirmed no shared radio/channel contention). Both grouped together in a larger Roon zone alongside several Bluesound and Devialet endpoints.

Symptom: frequent "long rtt sync" warnings in RoonServer_log naming both WiiM Pro and WiiM Sound, roughly once per minute during playback. Example:

Warn: [zoneplayer/raat] long rtt sync Linkplay Technology Inc. WiiM Sound: realtime=12657447121529 rtt=79583us offset=-1155362685us delta=65376us drift=68138us in 12657.077638s (5.383ppm, 19.380ms/hr)
Warn: [zoneplayer/raat] long rtt sync Linkplay Technology Inc. WiiM Pro Receiver: realtime=12379991290166 rtt=31113us offset=-1155988600us delta=-30176us drift=-63474us in 12380.29690875s (-5.127ppm, -18.457ms/hr)

No actual "Too many dropouts... Killing stream" event yet, but the pattern matches what led to that in the referenced thread.

What we ruled out: WiFi/channel contention. Explicitly pinned the two devices to separate APs on separate 5GHz channels (ch36 vs ch157), power-cycled both — warnings recurred within minutes regardless.

What actually stopped the error: removing either the WiiM Pro or the WiiM Sound from the Roon group. Zero "long rtt sync" warnings over a clean 10-minute plus test window afterward, versus the steady ~1/minute rate with both WiiM devices grouped together.

This points to something specific about two WiiM devices being clock-synced together in the same RAAT group, independent of network conditions — similar to the synchronization issue diagnosed in the WiiM Ultra thread. Is this a known interaction? Any firmware-side guidance from WiiM, or a Roon-side mitigation, for running multiple WiiM devices in the same group?

Describe your network setup

Multiple Unifi WAP and single Unifi Router

2

Hey @MvB,

Thanks for the detailed writeup, pinning the two devices to separate APs on separate channels and then A/B-ing group membership is exactly the right instinct, and it made your logs much faster to read.

We pulled the sync data out of them, and I think the picture is a little different from the WiiM-pairing theory.

On the warning itself: long rtt sync fires purely on round-trip time crossing 30ms, confirmed in your own logs, where the lowest rtt on any warning is 30.013ms and the highest on a non-warning is 29.845ms. The drift and ppm figures are downstream of that, since offset uncertainty scales with rtt, so a slow probe manufactures a large apparent drift. Those clocks are healthy, it’s the latency to them that isn’t.

On the grouping test: your logs already contain a longer version of it. The WiiM Sound still logged warnings, essentially unchanged from when both were grouped. Individual 10-minute windows in your logs range from 5% to 79%, so a single clean 10-minute run is within normal variance.

Would you be able to run a continuous ping to 192.168.40.228 from a wired machine during grouped playback?

Let us know the results, thank you! :+1:

3

Hey @benjamin

Thanks for digging into this. I ran the continuous ping you asked for.

ping -i 1 192.168.40.228 from a wired Mac on my network (Ethernet, not WiFi) to the WiiM Sound, for ~12.5 minutes during grouped playback.

Results:

  • 746 probes, 0% packet loss, no timeouts, no sequence gaps.
  • min 4.0ms / avg 14.8ms / max 155.2ms
  • 80 of 746 probes (10.7%) exceeded the 30ms threshold
  • Breakdown: 411 <10ms, 227 in 10–20ms, 28 in 20–30ms, 44 in 30–50ms, 27 in 50–100ms, 9 over 100ms (up to 155ms)
  • Spikes were spread fairly evenly across the whole run, not one burst — looks like ongoing low-grade latency/jitter to this device rather than a single event.

You’re right to suspect this is genuine network-path latency to that IP crossing your 30ms warning threshold on a regular basis, not a device-side clock issue.

I am not sure if there is anything else to do seeing it is network related, but if so I am happy to dig further on the network side (AP/channel/retry stats) if that’d help.

I can snd you the ping log file if you would like to see it as well.

4

Hello @MvB

We went through the full log set. Three things, and the first one changes the shape of the case.

Across five days of logs, long rtt sync breaks down by device like this:

WiiM Sound 5711
Bluesound NODE NANO 4732
Devialet Phantom 108 dB Stereo 191
WiiM Pro Receiver 167
Bluesound NODE 94
Bluesound POWERNODE 1

Your second-highest device is a Bluesound, not a WiiM. And the two leaders rise and fall together hour by hour. Taking 12 August:

hour NODE NANO WiiM Sound
03 377 374
04 180 195
15 387 335
16 350 314
18 731 725
19 506 463
22 350 345

Two devices from different manufacturers, on the APs and channels you separated, producing near-identical counts in the same hours. That is a shared constraint on the path they have in common, not something about two WiiM units being clock-synced to each other. It also explains why pinning them to separate radios changed nothing: the separation was real, but it was not where the limit is.

Killing stream has been happening. There are 135 of these in your logs, on the grouped zone:

Too many dropouts (>3s dropped out in the last 30s). Killing stream

By day: 5 on 09 August, 78 on 10 August, 45 on the 12th, 7 on the 13th. So the pattern you expected to lead there already has, including 78 events on the day you first wrote in.

On your ping result, it is more useful than you think, and also not the whole picture. A clean ping does not clear a path for RAAT, for three reasons:

  • An ICMP echo is answered by the device’s network stack. A RAAT sync is answered by its application, so the round trip also includes the device getting scheduled to do work. A busy or thermally limited endpoint adds latency that ping never sees.
  • Over TCP, one lost frame at the WiFi layer stalls everything queued behind it on that connection. A single 802.11 retransmission can add tens of milliseconds to a TCP round trip, where a lost ICMP echo only affects itself.
  • A once-per-second ping also keeps the client’s radio awake, which flatters the numbers relative to traffic that arrives in bursts.

The logs bear that out. Your ping peaked at 155ms. The highest sync round trip recorded in the logs is 554ms, well beyond anything your test saw. Your 10.7 percent over 30ms was measuring a real problem, just a milder version of it.

What we would do next. Your Roon Server is wired, and its interface is completely clean over the whole period: 52.9 million packets received, 123.6 million sent, zero errors, zero drops, zero overruns. So the server end is not contributing. That puts the constraint in the wireless segment, and since separate APs and separate channels did not help, above the radios rather than in them.

The decisive test is one cable. Please put either the WiiM Sound or the Bluesound NODE NANO on Ethernet, leave everything else as it is, and play the group for twenty minutes or so. If that device’s warnings stop while the other one continues at its usual rate, the wireless path is confirmed and we can stop looking at Roon and at the devices. If the wired device still logs warnings, that is a genuinely interesting result and we will want to see it.

5

Hello @MvB,

Were you able to try putting either the WiiM Sound or the Bluesound NODE NANO on Ethernet and then let the grouped zone run for about twenty minutes? That one-cable test is the key next step we mentioned, since it should tell us whether the warning counts follow the wired device or stay with the wireless path. If you have any results from that, or if the behavior changed in a different way, please send them over.

Please note, if we don’t hear back from you this thread may close automatically soon. If the thread auto-closes and you need further assistance, please submit a reopen support request via the technical support help form below and specify that the issue should be reopened. Thank you.