Cannot play local or Tidal content on my laptop[Fixed: Windows 10 NAT can break Roon playback]

Ping @support

I just set up Roon on my home server & laptop. I can stream to my Sonos devices via AirSonos, and to my desktop PC. However, whenever I try to stream Tidal or local content to my laptop, I get either the “TIDAL: A networking or connectivity problem is interfering with TIDAL playback” or “Roon: An audio file is loading slowly…” errors. I see network traffic of about ~1.5Mbps for a few seconds (in Task Manager), then that error pops up in Roon. I highly doubt my wireless network is the problem because I can reliably push 20-40Mbps. If I try to copy the album I’m playing from my server, it will get 20+Mbps. I tried both MP3 content (320k CBR), Tidal HiFi, and high res FLAC (24/96k)

Here’s my setup:

  • 1 server running multiple VMs
  • Windows Server 2012 R2, hosting file share with ~2TB of music
  • Ubuntu Server 16.04
  • Docker container running Roon Core (see my in progress blog post on GitHub for specific setup steps)
  • Docker container running AirSonos
  • Ubuntu VM has virtual NIC MTU set to 1500. It shouldn’t be attempting to send jumbo frames to the wireless clients.
  • Wired Gigabit Ethernet to several machines
  • 2 Airport Extreme 802.11n in different locations, different channels. Depending on location, my wireless clients will move between two different 2.4ghz and two 5ghz channels to find the strongest signal. There is no overlap.

I dug into firewall rules, and it looks like Roon added some for my local network:

PS C:\WINDOWS\system32> Get-NetConnectionProfile | ft Name, NetworkCategory

Name                     NetworkCategory
----                     ---------------
coffee.local  2      DomainAuthenticated
Unidentified network              Public
Unidentified network              Public
Unidentified network              Public
Unidentified network              Public


PS C:\WINDOWS\system32> Get-NetFirewallRule *roon* | ? Profile -eq "Domain" | ft Name, Enabled, Direction, Action -AutoSize

Name                                                                                                               Enabled Direction Action
----                                                                                                               ------- --------- ------
TCP Query User{C9C4ED56-7FD8-4304-9E57-AB07BFA174E1}C:\users\patrick\appdata\local\roon\application\roon.exe          True   Inbound  Allow
UDP Query User{98FC31B2-0656-44F6-888B-90DAE57E2311}C:\users\patrick\appdata\local\roon\application\roon.exe          True   Inbound  Allow
TCP Query User{0A5003E6-5108-4112-8BC6-55143FE85300}C:\users\patrick\appdata\local\roon\application\raatserver.exe    True   Inbound  Allow
UDP Query User{D159FF2D-73C5-4099-A204-47C6692F2618}C:\users\patrick\appdata\local\roon\application\raatserver.exe    True   Inbound  Allow

Where can I go to get more logs on what’s actually failing playing audio on my laptop? I’m not convinced this is a throughput issue since I can stream both my hires FLAC and Tidal Hifi outside of Roon with no problem at all.

Any thoughts? Are there any settings I need to check in firewalls, etc?

I dug into /var/roon/RoonServer/Logs and found this.

root@coldbrew:/var/roon/RoonServer/Logs# tail -n 120 RoonServer_log.txt
    Raat Device=System Output
    Output OutputType=Local_SharedMode_Wasapi Quality=HighQuality
------------------------------------------------------------

11/15 06:28:05 Trace: [transport/raatclient] SENT [19]{"request":"setup","format":{"sample_type":"pcm","sample_rate":96000,"bits_per_sample":24,"channels":2}}
11/15 06:28:05 Trace: [prebuffer] ready 326400/960000 (34%) @ 0/321 sec
11/15 06:28:05 Trace: [transport/raatclient] GOT [19] {"status":"OutputMessage","message":{"signal_path":[{"type":"output","quality":"high","method":"wasapi_shared"}]}}
11/15 06:28:05 Info:
--[ SignalPath ]---------------------------------------------
SignalPath Quality = HighQuality
Elements:
    Source Format=Flac 96000/24/2 BitRate=3042 Quality=Lossless
    Raat Device=System Output
    Output OutputType=Local_SharedMode_Wasapi Quality=HighQuality
------------------------------------------------------------

11/15 06:28:05 Trace: [transport/raatclient] GOT [19] {"audio_port":50005,"status":"Success","clock_port":50004}
11/15 06:28:05 Trace: [zoneplayer/raat] Endpoint System Output State Changed: Idle => Prepared
11/15 06:28:05 Trace: [zoneplayer/raat] _StartStream2 streamid=1140397499
11/15 06:28:05 Trace: [zoneplayer/raat] synced to endpoint clock. realtime=37171500 rtt=1664us offset=-117852413us delta=-117852413us
11/15 06:28:05 Trace: [zoneplayer/raat] _StartStream3 streamid=1140397499
11/15 06:28:05 Trace: [transport/raatclient] SENT [20]{"request":"stream","stream_id":1140397499,"first_seq":596,"nak_port":51117}
11/15 06:28:06 Trace: [transport/raatclient] GOT [20] {"status":"Buffering"}
11/15 06:28:06 Trace: [zoneplayer/raat] Endpoint System Output State Changed: Prepared => Buffering
11/15 06:28:06 Trace: [zoneplayer/raat] _StartStream4 streamid=1140397499
11/15 06:28:06 Trace: [raat/audiosource] -------------------------[ FLUSH ]-----------------------------
11/15 06:28:06 Trace: [raat/audiosource] setting stream bitrate to 4608000 (9216000 with headroom)
11/15 06:28:06 Trace: [prebuffer] status 960000/960000 (100%) @ 0/321 sec
11/15 06:28:10 Info: [stats] 1287mb Virtual, 350mb Physical, 53mb Managed, 0 Handles, 55 Threads
11/15 06:28:11 Warn: [zoneplayer/raat] Endpoint failed to become ready in 5s. Proceeding in state Buffering
11/15 06:28:11 Trace: [zoneplayer/raat] Endpoint System Output State Changed: Buffering => Ready
11/15 06:28:11 Info: wait for ready in 5002ms
11/15 06:28:11 Trace: [zoneplayer/raat] Adjusting playback start offset from 270ms to 200ms
11/15 06:28:11 Trace: [zoneplayer/raat] Starting at streamsample 0 and time 5835845500 in thread Thread[Id=39320, Name=] min_offset=270ms offset=270ms
11/15 06:28:11 Trace: [transport/raatclient] SENT [21]{"request":"start","time":5835920500,"stream_sample":0}
11/15 06:28:11 Trace: [zoneplayer/raat] Endpoint System Output State Changed: Ready => Playing
11/15 06:28:11 Trace: [prebuffer] status 960000/960000 (100%) @ 2/321 sec
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Playing"}
11/15 06:28:12 Trace: [transport/raatclient] GOT [21] {"status":"Success"}
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:12 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":10560}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:13 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":10560}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":10560}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:14 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
11/15 06:28:15 Trace: [zoneplayer/raat] too many dropouts. stopping stream
11/15 06:28:15 Trace: [zoneplayer/raat] Endpoint System Output State Changed: Playing => Prepared
11/15 06:28:15 Trace: [transport/raatclient] SENT [22]{"request":"end_stream"}
11/15 06:28:15 Info:
--[ SignalPath ]---------------------------------------------
SignalPath Quality = Inactive
Elements:
------------------------------------------------------------

11/15 06:28:15 Warn: Track Stopped Due to Slow Media
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
11/15 06:28:15 Trace: [zoneplayer/raat] too many dropouts. stopping stream
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
11/15 06:28:15 Trace: [zoneplayer/raat] too many dropouts. stopping stream
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":10560}
11/15 06:28:15 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
11/15 06:28:15 Trace: [zoneplayer/raat] too many dropouts. stopping stream
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
11/15 06:28:15 Trace: [zoneplayer/raat] too many dropouts. stopping stream
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
11/15 06:28:15 Trace: [zoneplayer/raat] too many dropouts. stopping stream
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Dropout","samples":9600}
11/15 06:28:15 Warn: [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
11/15 06:28:15 Trace: [zoneplayer/raat] too many dropouts. stopping stream
11/15 06:28:15 Trace: [transport/raatclient] GOT [20] {"status":"Ended"}
11/15 06:28:15 Trace: [transport/raatclient] GOT [22] {"status":"Success"}
11/15 06:28:20 Trace: [zone] no playback for 5s, suspending to release audio device
11/15 06:28:20 Trace: [zone] [X250 System] Suspend
11/15 06:28:20 Trace: [zone] [X250 System] Stop
11/15 06:28:25 Info: [stats] 1287mb Virtual, 351mb Physical, 57mb Managed, 0 Handles, 54 Threads
11/15 06:28:40 Info: [stats] 1287mb Virtual, 351mb Physical, 57mb Managed, 0 Handles, 51 Threads
11/15 06:28:48 Trace: [library] endmutation in 11ms
11/15 06:28:55 Info: [stats] 1287mb Virtual, 351mb Physical, 58mb Managed, 0 Handles, 68 Threads
11/15 06:29:10 Info: [stats] 1287mb Virtual, 351mb Physical, 58mb Managed, 0 Handles, 51 Threads
11/15 06:29:25 Info: [stats] 1287mb Virtual, 351mb Physical, 58mb Managed, 0 Handles, 63 Threads

If I play a 24/96k FLAC file, I see it buffer at several Mbps then… nothing.

My wifi connection is currently connected at 802.11n channel 157 (5ghz), 99% signal, 300Mbps.

Hi @Patrick_Lang ——— Thank you for the report and apologies for the troubles. Based on your feedback and logs, our first step here should be to look into any potential networking issues.

Troubleshooting network configurations often comes down to trial and error, or process of elimination. The fastest path forward tends to be a) simplify things to as simple as they can possibly be, b) confirm the issue is resolved, and c) add complexity back in, one piece at a time, until the problem recurs. My advice would be to simplify your network and see if there’s any difference.

Moving forward, can you you confirm if you are able to stream content from TIDAL via a web browser and/or the application? Being as your current setup has a bit of complexity, the ideal starting point to troubleshoot your network should resemble something close to this:

Example (No Wifi / No VMS): Internet Connection - > Router - > OS running Roon.

We do a lot of network troubleshooting here, and we usually end up nailing the problem, even in those cases when it ends up not being a networking problem at all. Just wanted to give you that background as we continue to dig into this issue for you.

I have also left a note with my developers to offer some insight here to see if they have any theories as to what may be causing this to happen. I look forward to hear your observations!

-Eric

Thanks for getting back to me!

Tidal works flawlessly on my laptop and phone on the same wifi network. I can listen to Tidal using their app on the same network while my wife streams Netflix/Hulu and neither of us have any dropouts.

I can’t rip apart my whole network, but I can try the following:

  • Isolate wifi network segment
  • See if there’s any difference using the current laptop on Ethernet instead of wifi
  • Double check another laptop on the same wifi network
  • Remove Linux from the picture & install Roon Core on my desktop Windows 10 PC, and see if I can stream to the laptop successfully (Remove Linux VM & containers from the picture, but keep the same Ethernet & wifi infrastructure)

With that said, I don’t want to run Roon on my desktop PC long term. It’s too loud and power hungry since I built it for gaming. I have a low power nearly silent PC running as a VM+fileserver right now and that’s where I want Roon to live.

Hi @Patrick_Lang ----- Thank you for the feedback and taking the time to share your observations with me :+1:

I completely understand and respect your your wanting Roon to live on a quite PC and I am confident that we can figure a way to make this configuration work for you. Let’s eliminate some variables, as you have proposed above and see where we land. I am eager to hear your feedback and get this resolved!

-Eric

Alright - first experiment. Laptop plugged directly into Ethernet switch that’s plugged into my router.

Apple Airport Extreme (router) -> D-Link DGS-1008G -> laptop. Tidal works (official client). Roon fails to stream Tidal, MP3 content, and high res FLAC. I tried built-in audio, and Dragonfly - no difference.

Here’s the server side log:

11/17 06:26:12 Info: [zoneplayer/base] Playing: http://5e.audio-pop.tidal.com/40889495/92b07ed8f7e2b4d88105bb8f98750674_26.flac?__token__=exp=1479365771~hmac=7a8f624bdb0e9ca95a5363eb532c523ba6dc12d0d262796866eb11a766141990
11/17 06:26:12 Info: [zoneplayer/base] Queueing: http://e0.audio-pop.tidal.com/79789495/c5aa3ca9630622b22279cf13a6d83a3c_26.flac?__token__=exp=1479365771~hmac=702b8b1061af7acf56165ff901868c2bbe7f675fe5027dc57b3f77b32bed1435
11/17 06:26:13 Info: [zoneplayer/base]     Open Result (Playing):Result[Status=Success]
11/17 06:26:13 Info: [zoneplayer/base] Starting playback
11/17 06:26:13 Info:
--[ SignalPath ]---------------------------------------------
SignalPath Quality = HighQuality
Elements:
    Source Format=Flac 44100/16/2  Quality=Lossless
    Raat Device=AudioQuest DragonFly Red v1.0
    Output OutputType=Local_SharedMode_Wasapi Quality=HighQuality
------------------------------------------------------------

11/17 06:26:13 Trace: [zoneplayer/raat] StartStream StreamFormat(channels=2, bitspersample=16, samplerate=44100, isdts=False streamid=481846231
11/17 06:26:13 Info:
--[ SignalPath ]---------------------------------------------
SignalPath Quality = HighQuality
Elements:
    Source Format=Flac 44100/16/2  Quality=Lossless
    Raat Device=AudioQuest DragonFly Red v1.0
    Output OutputType=Local_SharedMode_Wasapi Quality=HighQuality
------------------------------------------------------------

11/17 06:26:13 Trace: [zoneplayer/raat] _StartStream2 streamid=481846231
11/17 06:26:13 Trace: [zoneplayer/raat] synced to endpoint clock. realtime=70397119016 rtt=961us offset=-25692537us delta=-25692537us
11/17 06:26:13 Trace: [zoneplayer/raat] _StartStream3 streamid=481846231
11/17 06:26:13 Trace: [transport/raatclient] SENT [27]{"request":"stream","stream_id":481846231,"first_seq":1594,"nak_port":47703}
11/17 06:26:13 Trace: [transport/raatclient] GOT [27] {"status":"Buffering"}
11/17 06:26:13 Trace: [zoneplayer/raat] Endpoint AudioQuest DragonFly Red v1.0 State Changed: Prepared => Buffering
11/17 06:26:13 Trace: [zoneplayer/raat] _StartStream4 streamid=481846231
11/17 06:26:13 Trace: [raat/audiosource] -------------------------[ FLUSH ]-----------------------------
11/17 06:26:13 Trace: [raat/audiosource] setting stream bitrate to 1411200 (2822400 with headroom)
11/17 06:26:13 Trace: [prebuffer] status 52920/441000 (12%) @ 0/166 sec
11/17 06:26:13 Info: [zoneplayer/base] Open result (Queueing): Result[Status=Success]
11/17 06:26:13 Trace: [prebuffer] ready 149940/441000 (34%) @ 0/166 sec
11/17 06:26:13 Trace: [prebuffer] ready 149940/441000 (34%) @ 0/118 sec
11/17 06:26:14 Info: [stats] 1413mb Virtual, 378mb Physical, 63mb Managed, 0 Handles, 93 Threads
1 Like

When I play from the desktop that works (Core is unchanged - still running in container in Linux VM) on same wired net, CPU usage all looks in line:

CONTAINER           CPU %               MEM USAGE / LIMIT       MEM %               NET I/O             BLOCK I/O             PIDS
a5                  18.24%              614.6 MiB / 1.945 GiB   30.86%              0 B / 0 B           429.5 MB / 19.57 MB   90
1 Like

Alright - I think I’m getting much closer to the root of the problem. Is the Raat protocol UDP based? If so, I suspect it bound to the wrong interface. I do development work on this laptop, so my typical network stack includes multiple non-routable internal interfaces:

PS C:\WINDOWS\system32> ipconfig

Windows IP Configuration


Ethernet adapter vEthernet (pfSense-Internal):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::4076:b876:abc2:a722%16
   IPv4 Address. . . . . . . . . . . : 10.0.7.16
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (DemoNet):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::b56d:67cd:1ebb:ec0f%33
   IPv4 Address. . . . . . . . . . . : 192.168.5.2
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 192.168.5.4
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (HNS Internal NIC):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::60d1:5303:7a05:42d%20
   IPv4 Address. . . . . . . . . . . : 172.16.0.1
   Subnet Mask . . . . . . . . . . . : 255.240.0.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (hyperv_Private):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::c00d:79e6:4c93:3c2e%19
   Autoconfiguration IPv4 Address. . : 169.254.60.46
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (Wifi):

   Connection-specific DNS Suffix  . : hsd1.state.comcast.net
   Link-local IPv6 Address . . . . . : fe80::bd7a:a52:f003:f36c%27
   IPv4 Address. . . . . . . . . . . : 192.168.1.115
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

Ethernet adapter vEthernet (Ethernet):

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : hsd1.state.comcast.net

Wireless LAN adapter Local Area Connection* 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{84EC70AA-48B7-4EA5-927F-8C8973E95122}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.hsd1.state.comcast.net:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : hsd1.state.comcast.net

Tunnel adapter isatap.{8A6BAA72-45C7-416E-AC98-BAE4C14BE17A}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{7DF0D053-74B0-49BA-8C67-57B37B5A4E91}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{E251FAAF-3211-4932-983E-F79A13BB1A9F}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

I took out the big hammer and shut all of them down, and now it’s streaming over Wifi:

PS C:\WINDOWS\system32> ipconfig

Windows IP Configuration


Ethernet adapter vEthernet (hyperv_Private):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::c00d:79e6:4c93:3c2e%19
   Autoconfiguration IPv4 Address. . : 169.254.60.46
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (Wifi):

   Connection-specific DNS Suffix  . : hsd1.state.comcast.net
   Link-local IPv6 Address . . . . . : fe80::bd7a:a52:f003:f36c%27
   IPv4 Address. . . . . . . . . . . : 192.168.1.115
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

Ethernet adapter vEthernet (Ethernet):

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : hsd1.state.comcast.net

Wireless LAN adapter Local Area Connection* 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.{84EC70AA-48B7-4EA5-927F-8C8973E95122}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Tunnel adapter isatap.hsd1.state.comcast.net:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : hsd1.state.comcast.net

Tomorrow I’ll try re-enabling those one by one to see which one breaks it.

1 Like

RAAT does use UDP

1 Like

Thanks! So now the question is - how does Roon decide where to send the UDP traffic? It’s probably picking the wrong destination IP for my laptop. The logs above show port numbers 50005, 50004, but not what IP it’s sending traffic to.

RAAT uses a TCP control connection and then performs clock synchronization/recovery using UDP, then sends the audio stream using UDP. Discovery is done using multicast + broadcast UDP.

The symptoms you’re describing sound like you have working discovery, and a working TCP control connection, and working UDP clock synchronization exchanges, but that UDP audio packets aren’t flowing.

A few thoughts…

Regarding Jumbo Frames

RAAT transmits audio in large UDP packets (~4k). On the majority of networks without Jumbo frame support, these are fragmented in the kernel and then reassembled on the receiving end.

However, if the network is misconfigured in such a way that some nodes support Jumbo frames and others do not, then it can produce symptoms like this: the Roon Core sends large UDP packets, and then the kernel emits large ethernet frames. The node at the receiving end (or some node in the middle) drops them because they exceed MTU. At the application level, it’s as if the UDP packets don’t exist from the perspective of the receiving end.

I can’t say for sure if this is your issue, but it is very consistent with your described symptoms.

If you think there’s a possibility that your network has Jumbo frame support enabled inconsistently, I recommend starting by turning it off everywhere to confirm the theory, then working on getting it turned back on.

Regarding UDP destination addresses

RAAT uses a TCP control connection and then sends the audio stream using UDP. The UDP packets are addressed to the remote address of that control connection. UDP packets are only sent after some messages are exchanged over the TCP connection, so there’s a good reason to believe that it’s up, and that that IP correctly represents the remote end.

Given this–it’s hard to see how they could be going to the wrong address.

Troubleshooting further

The goal should be to figure out what part of your network is stopping the UDP audio packets from flowing. If this were all in front of me, I’d be using tools like tcpdump or wireshark to see where the audio stream is (and isn’t) flowing.

Thanks for the detailed info Brian!

I fired up NetMon 3.4, and am seeing UDP packets fragmented normally into 1514 byte frames and reassembled correctly.

Frame: Number = 2257, Captured Frame Length = 1514, MediaType = ETHERNET

2255	4:29:24 PM 11/21/2016	19.2092371		192.168.1.143	192.168.1.115	IPv4	IPv4:[Fragment, Offset = 1480] Src = 192.168.1.143, Dest = 192.168.1.115, Next Protocol = UDP, Packet ID = 5734, Total IP Length = 1500	{IPv4:1}
2256	4:29:24 PM 11/21/2016	19.2093169		192.168.1.143	192.168.1.115	IPv4	IPv4:[Fragment, Offset = 2960] Src = 192.168.1.143, Dest = 192.168.1.115, Next Protocol = UDP, Packet ID = 5734, Total IP Length = 1208	{IPv4:1}
2257	4:29:24 PM 11/21/2016	19.2408513		192.168.1.143	192.168.1.115	UDP	UDP:SrcPort = 44161, DstPort = 50289, Length = 4148	{UDP:54, IPv4:1}

I did more digging, and it seems like the only variable that matters is whether or not winnat is present. This isn’t supposed to effect traffic going to my laptop and should be used for containers & VMs only. However, once I remove it, Roon works normally. In both cases, my traffic capture on the wifi interface show all Ethernet packets arriving. When WinNAT is enabled, it looks like it is dropping all UDP packets rather than passing them back to the host.

I found this performance counter which leads me to think that is indeed the case.

\WinNAT UDP\NumPacketsDropped = 3872

Is there anything I can do to tell if RoonServer is receiving any UDP at all? Knowing if it’s all or just some getting through can help narrow this down further.

There isn’t any logging to turn on, but I can answer the question based on what you’ve shared so far.

RoonServer uses UDP for discovery–if it’s able to discover RAATServer, or Roon Ready devices, then it’s successfully at least receiving UDP packets.

If your remote can discover RoonServer, then you can infer that RoonServer is sending UDP packets successfully.

We know that clock synchronization is working from your RAAT logs, so both RoonServer + RAATServer are sending + receiving UDP packets successfully.

So I think it’s safe to say that everyone can both send and receive some UDP packets.

The only UDP packets that seem to be missing are the audio stream, which flows from RoonServer -> RAATServer.

Can the logs rule out:

  • unicast vs multicast? It seems that discovery could be multicast
  • packet size? Are the audio packets the only ones > 1500 bytes?

Well nevermind, ICMP is messed up too.

ICMP echos at 4000 bytes fail until I remove the Nat.

PS C:\ProgramData\docker\network\files> ping 192.168.1.1 -l 4000

Pinging 192.168.1.1 with 4000 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 192.168.1.1:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
PS C:\ProgramData\docker\network\files> ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms
Control-C
PS C:\ProgramData\docker\network\files> Get-NetNat | remove-netnat

Confirm
Are you sure you want to perform this action?
Performing operation Delete on Target nat PolicyStore Local
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):
PS C:\ProgramData\docker\network\files> ping 192.168.1.1 -l 4000

Pinging 192.168.1.1 with 4000 bytes of data:
Reply from 192.168.1.1: bytes=4000 time=4ms TTL=255
Reply from 192.168.1.1: bytes=4000 time=3ms TTL=255
Reply from 192.168.1.1: bytes=4000 time=4ms TTL=255

Ping statistics for 192.168.1.1:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 4ms, Average = 3ms
Control-C

While NetMon shows all frags were received:

72	9:08:14 PM 11/21/2016	6.8379768		192.168.1.1	192.168.1.115	ICMP	ICMP:Echo Reply Message, From 192.168.1.1 To 192.168.1.115	{IPv4:26}
73	9:08:14 PM 11/21/2016	6.8383313		192.168.1.1	192.168.1.115	IPv4	IPv4:[Fragment, Offset = 1480] Src = 192.168.1.1, Dest = 192.168.1.115, Next Protocol = ICMP, Packet ID = 20805, Total IP Length = 1500	{IPv4:26}
74	9:08:14 PM 11/21/2016	6.8383598		192.168.1.1	192.168.1.115	IPv4	IPv4:[Fragment, Offset = 2960] Src = 192.168.1.1, Dest = 192.168.1.115, Next Protocol = ICMP, Packet ID = 20805, Total IP Length = 1068	{IPv4:26}

Discovery is both multicast announce/unicast reply. If discovery replies are working, then unicast is working.
Audio packets are the only thing that should be >1500.

Alright, that’s consistent with SSDP which also works. I’ll see what I can find with my contacts at Microsoft.

I forgot to mention this earlier. The issue with UDP & ICMP fragment reassembly was fixed in the Windows 10 Creators Update. To check your version, run winver.exe. Version 1703 = Creators Update.

If any moderators are watching - can you change the title of the thread to something like “Fixed: Windows 10 NAT can break Roon playback”

1 Like