Sonos stability issues ("Roon lost control...)

I experience similar symptoms with Roon and Sonos with no resolution.

My system sounds somewhat similar: 100% Ubiquity UniFi gateway, switches, WiFi with multiple Sonos devices. WD gigabit NAS device serving music to Roon. Roon Server on Win10 headless. Sonos devices attached to same switch, but Roon server attached to different switch at the same STP priority level as the Sonos devices. Both Sonos switch and Roon switch uplink to a Core switch.

I’ve experienced NO problems with Sonos app and connectivity in ~7+ years of using the Sonos system, now with UniFi access points throughout the house.

Roon repeatably shows “Roon Lost Control…” of the Sonos device for playback. I went through many iterations of tearing down Sonos connectivity to find a possible solution in case Sonos connectivity is the problem: forcing STP priorities to the Ubiquity switches, going all-hard-ethernet-wired, one-device-hard-wired, using only Sonos CONNECT/BRIDGE, and now back to all on UniFi WiFi with strong signals and without a CONNECT). All with same symptoms.

The symptom appears after several times hitting “play” or “Rewind” or “Fast Forward” to skip through or replay song(s). The particular songs I first discovered this on were 24-bit and 32-bit WAV test audio files from REW (logarithmic sine test sweep) that seem to be “worse” for creating the symptom. But I also see this with ALAC versions of the same files, and also I’ve observed with ALAC CD rips.

Here are other observation, if not clues:

  1. When playing 24-bit REW test files, sometimes the playback is normal, but sometimes the playback audio is “warbled” meaning instead of a sine sweep, I hear like a dual-tone effect or high and low tones. Perhaps as if the audio packets or waveform is played out-of order? When this symptom happens, I often get the transport lost with repeated rewinds.
  2. This warbling and “lost transport” does NOT happen when streaming to a Yamaha receiver Airplay device on the same network level.
  3. I have no Roon DSP effects or EQ enabled, but do have headroom and zone volume adjustment enabled.Yet the “playback performance” bounces all around for each replay. From “1.5X”, 2.4X, sometimes 8X and sometimes nothing is shown…I’d expect that I have plenty of processing speed available. The files have been imported (volume leveling calc by Roon I assume), Roon Server is a dedicated gen 7 Core i5 NUC, gigabit network and ports for the Win10 machine and the WD NAS.
  4. I don’t believe I get this symptom streaming FLAC from Tidal.
  5. Also doing the same rewind/skip in Sonos app does NOT cause the symptom.

Could this be an issue of timeouts or not enough buffering between NAS-to-RoonServer-to-Sonos?

@Support
It’s been 3 weeks since my post on Sonos functionality with Roon, and no update. Shall I begin suspecting that Roon does not truly support transport of music to Sonos devices?

My experience shows that Roon is repeatably not reliable with Sonos devices over wireless, mixed enet+SonosNet or WiFi. A search of other posts shows similar concerns, extending to RAAT lost connections as well.

How will reliability be fixed, when it seems to work with other protocols (e.g. Sonos controller-to-Sonos devices)?

Hi @NokiaFanToo ---- Thank you for the report and sharing these observations you have made while using your Sonos endpoints with Roon. My sincerest apologies for the very slow response here. I have moved your posts over to their own thread so we can address this behavior with you directly.

Moving forward, I have all the details of your setup and the testing you have done thus far which I will be adding to your ticket for feedback from our tech team. Additionally, I would also like enable diagnostics on your account so our team can have a closer look into this behavior as this action will automatically generate/upload a diagnostics report containing a set of your Roon logs directly to our servers. But before I do that may I very kindly ask you to please perform the following:

  • Please reboot your core machine.

  • Once your Roon core is back online please reproduce the issue and note the time when the error is observed

    “The symptom appears after several times hitting “play” or “Rewind” or “Fast Forward” to skip through or replay song(s).”

  • Also note what was playing at the time when the above was performed.

-Eric

@Eric, OK Thank you for your response.

I have replicated the issue on 3 different sonos devices, each within 4-15 feet of a UniFi WiFi access point. UniFi reports strong signal/noise ratios from these devices. The music source – to eliminate possibility of NAS being a culprit – was ALAC files on my Roon core server (Win10) SSD drive.

The “lost transport” and warble sound symptoms were reproduced at time 11:49AM PST and continued through 11:58AM PST 02/03/2018 after which I stopped checking that Sonos device.

On a different Sonos device, a new symptom/behavior. Got some warbling on some songs, but new: songs would not progress or play even with hitting the “play” button multiple times. Observed 12:03 - 12:19PM PST 02/03/2018. Only way to get sound to play when it is stuck is with rewind/skip or skip/rewind sequence to re-start the song. This sonos device is closest to wifi access point (5 feet) so signal should be strongest.

Does this fit to your story?

https://community.roonlabs.com/t/transport-error-due-to-potential-memory-leak-prevents-playback-on-sonos-devices/37234?u=retlaw

Thanks for the follow up and feedback @NokiaFanToo, very appreciated!

As mentioned in my previous, now that I have the requested time frames I have went ahead and enabled diagnostics on your account. The next time Roon is active on your core machine the report should automatically be uploaded to our servers for analysis.

Once the report comes in I will follow back up so you know we have it and then pass it over to our techs for further investigation.

-Eric

Hi @NokiaFanToo ---- Touching base to let you know that I have received the report (thank you again), which has now been attached to your ticket for review by our DEV team.

Once your ticket has been updated/passed back, I will be sure to share the team’s thoughts/findings with you ASAP. Your patience while we the team conducts their analysis is VERY appreciated!

-Eric

@Eric, Thank you.

FYI I replicated the issues with an updated system network architecture, just to eliminate potential concerns about my system’s network.

Originally Roon was on a separate managed switch from the Sonos-connected WiFi AP’s. So traffic had to go through a couple of managed switch hops (always through managed UniFi gigabit switches). These were the test results indicated in the Feb 03 post.

I subsequently broke my structured wiring rules and put Roon and WiFi APs onto the same managed switch (They have always been on the same VLAN subnet). That way there should be no question of possible network delays.

Even so, I was able to easily repeat the symptoms at 8:58AM, 9:45 AM, and again at 9:44PM PST Feb 8, 2018.

@Retlaw sorry, I just saw your post. Interesting symptom you report, however my symptoms are observed recently only ~8 hours directly after a reboot. Duty cycle of playing music has been 0% since Roon is currently not reliably working with my Sonos (although Sonos app is very stable for playback). Roon system is Win10 64-bit, 8GB SDRAM.

Thanks for the insight @NokiaFanToo, I have re-enable diagnostics on your account so we have these test runs in an up to date report which I will be attaching to your ticket once received.

Your continued patience is very appreciated!
-Eric

Hi @Eric this may be placebo effect but this seems to improve the frequency of “Lost Transport” symptoms: I installed the Windows Sonos Controller app onto the (headless) Win10 Roon Server.

In brief testing, repeating the above forward/rewind sequences does not replicate the “Lost Transport” symptom. I’ll continue testing.

By installing the Sonos app, Defender firewall opens TCP protocol 6 and UDP protocol 17 (all ports).

One symptom does persist, where Roon doesn’t advance through or play the music file after hitting Rewind/Skip.

@Eric, an update-- subsequent testing indicates that disabling Windows Defender Firewall did not resolve the “Lost Transport” issue.

Opening all ports in Defender on my Roon server (Win10 headless) made the “Lost Transport” symptom less frequent, but it still occurs, repeatably with skip/repeat or scrubbing through the music scroll bar. This symptom never occurs when using the Sonos App directly.

Are there some things I can try, in testing whether there is an issue with Roon + Sonos robustness to packet loss or out-of-order on control and state packets --.either outbound (Control packets like “play” “stop”?) or inbound (Sonos/UPnP state packets?).

Hi @NokiaFanToo ---- Thank you for your patience and my apologies for the slow response.

To offer a quick update, this issue has been with our tech team who have been vigorously trying to reproduce this issue in our QA lab so we can have a better understanding of what could potentially be causing this behavior to occur. This has been quite the challenge for the team as our attempts to reproduce the problem in house have had mixed/varying results. As you are aware, in order for us to address the issue we must first be able to replicate it.

Part of the challenges we are facing stem from the fact that everyone has a different network configuration with a varying amount of devices being implemented (routers, switches, powerline adaptors, etc). So pinpointing the variable(s) that could be influencing the performance of our Sonos integration has been quite arduous. Our plan is to set up some field testing in an environment where the issue can easily be replicated.

-Eric

Hello @Eric I appreciate the update.

I understand the difficulty of reproducing the symptom, since I also find it intermittent – some days in the same setup I can reproduce it with a single “FF/Skip,” and other times the system appears to be quite robust.

After spending tons of time trying to test adjustments on my end, three observations I have may be enlightening to your engineers (or not) – possibly centered around robustness to dropped Roon control or state packets?

  1. Roon commands – network packet drops or delayed?
    The symptom easily appears when issuing a Roon commands like Skip, Rewind, Fast Forward, scrub from Roon remote (but not from Sonos app). But I can play a Roon queue (without any manual FF/RW) all day/all night with no “Lost Transport” symptoms, I even used -noflac switch on the server to load the bandwidth with all units playing OK continuously.

I wondered if my network was dropping or delaying Roon music control packets? I found that my UniFi gateway CPU was 60% avg. utilized, so maybe CPU was peaking and causing drops – I had it segmented to route some non-Roon devices between VLAN subnets IoT (mostly high BW IP Cams) and DMZ. Putting them all on the same subnet is less secure but got the gateway CPU down to negligible utilization. Oh, I also segregated other WiFi devices onto a totally different 5G-only SSID, away from the 2G Sonos devices.

At first this appeared to help Roon, but alas, no, the symptoms still appear :frowning:

  1. Roon commands dropped/delayed on WiFi?
    Observation is it seems Sonos app is able to be more robust to WiFi dropped packets and re-try delays, whereas Roon appears to be more fragile.

A deep dive into my Sonos phyerr stats and Unifi WiFi analytics showed me some of the Sonos units exhibit high WiFi error re-tries. Strange, the UniFi transmit and receive stats show a strong signal, and I’ve done WiFi channel mitigation to minimize interference. But I DO live in a WiFi dense city, no way around some WiFi interference, yet Sonos app does work in these conditions.

UniFi analytics tell me that receiving FROM the Sonos units, there sometimes can be high retry in the range of 20%, and sporadic dropped Rx packets (5-10 per minute) depending on interference.

Again, Sonos appears to handle this lossy condition, Roon mostly handles this if I just play a queue without FF/REW. But if I mess with FF/Skip/REW, I can re-create the “Lost Transport” symptom in Roon.

  1. Roon + Sonos queuing up a song peaks the Roon server CPU? Peaks the network?
    I can usually make the “Lost Transport” symptom happen with high probability using just a few test ALAC or WAV source songs (below). Although I do see the symptom with various other source material like ALAC CD rips and Tidal FLAC as well.

I have no DSP effects enabled except volume leveling, music has been scanned and leveled, and I test using source songs on the headless Roon server’s SSD.

Something with these music files? Something with setting auto-leveling or volume normalization? They are created with REW and ALAC encoded in iTunes:

Hi,

I’m also having terrible Sonos reliability when playing to grouped Sonos devices via Roon. No problems with playing from the Sonos app.

I’d like to add an additional observation to what’s already been stated though: Most of my problems reliably occur when I group 3 or more Sonos devices (zones), and one of the ‘devices / zones’ is a pre-defined Sonos pair, in my case a Play5 + Sub. If I group 3 or more devices and none of those devices are ‘pre-paired’ devices such as a device+sub, or a left/right stereo pair, then I don’t seem to experience nearly the same problems.

It’s pretty clear to see the problem by opening the Sonos app on a Mac, and watching the “Rooms” group together and ungroup while controlling from Roon. The moment I have Roon group 3 Sonos “Rooms”, and one of those is a “Play5 + Sonos Sub”, the groupings go wacky and it’s all downhill from there.

I hope this helps. I can possibly take a video of the Sonos app and adjacent Roon App demonstrating this, if you can’t reproduce.

Hi,

I am testing Roon for two weeks now and decided to use it in the future. The Roon Server is running on a Windows 10 x64 PC right now (but my NUC for my planned ROCK installation is on the way). I have three Sonos devices in my network connected via my WiFi network (not the Sonos Mesh-WiFi). Up to now I was able to play back all audio files without any problem.

Yesterday I saw the “Roon lost control…” message for the very first time. Before the message appeared I did some “heavy” skipping between tracks and I also used the waveform in the Roon app to navigate to specific points of the audio files.

After the message appeared I tried the Sonos app. Playback worked as usual but still no chance of starting playback with the Roon app.

After that I restarted Roon Core which made no difference. This specific Sonos device was still not available to Roon after relaunching. All other Sonos devices worked as usual with Roon.

After rebooting the Sonos device I was able to use it again.

Indeed it appears that skipping tracks quickly in succession will trigger the ‘roon lost control…’ issue with sonos. I am grouping two sonos speakers and I notice that I can skip tracks 7 times in succession before roon loses control. As long as I avoid skipping too much, no problem at all.

Once roon loses control of a sonos device then you cannot start play again (via Roon). No need to reboot the device though. I noticed that if you wait a few minutes before hitting play (via Roon) then sonos will again work via Roon.

Hope this helps a bit.

1 Like

Thank you everyone for the feedback and sharing what your experience has been like with Roon + Sonos. The feedback has been both appreciated and extremely valuable to our investigation.

I am going to be adding everyone’s information (and provided materials, thanks @NokiaFanToo) to the ticket we’re using to gather information/track this issue. As mentioned our plan is to do some field testing in a user’s environment where this issue is prevalent and easily reproducible. We have a contact from the area whom we will be coordinating with and as we make progress I will be sure to keep everyone up to date.

-Eric

A post was merged into an existing topic: Have to reboot Sonos Connect - “Roon lost control…”

Sonos Update leading again to „lost control“-issue - Nucleus
Updating alle Sonos-Apps and Sonos-devices did not help (you have to do that anyway). Rebooting Sonos-devices did not help. Restarting (Nucleus-)Server-Software did.