Just posted and then saw this - kind of rules out a Bootcamp issue then.
Yeah, I have a Windows 8.1 machine and a Windows Server 2012 R2 machine that present the same issue.
As a follow-up, I am streaming from the MacBook Pro running OS X to the Sonicorbiter SE at DSD256 and 24/352.8 into a Mytek Brooklyn without a single issue.
What about Windows 10 to the SE to the Mytek? Same issue or OK?
By the way - looking forward to your review on the Brooklyn. Close to buying one.
Itās probably of no help because you guys know networking far better than me, but the only time Iāve experienced anything like this in the past - where a network was robust for one OS and not for another - was when a ānon standardā MTU was set somewhere in a switch/hardware firewall box. This made all our Macās on a subnet go weird (but only in certain circumstances), yet the linux and windows machines were unaffected. It took a long time to track down as there were a few systems involved. Probably a red herringā¦ā¦
Thanks for the suggestion.
Windows 10 to SE to Mytek = same issue.
I tried DSD128 (from Windows) to the SE t0 the Mytek and the music stops playing only a few seconds into the track. I know this was requested by @brian a while ago.
This matches my experience. My iMac running Roon core on OS X seems to work without issue. My Nuc running Roon Core Windows 10 to SOSE has issues at 192 or above.
Have you guys tried disabling the extra services on the Windows network interface one at a time?
IPV6
QOS
File & Print Sharing
etc
Not yet. Good suggestion.
I have tried different combinations of disabling networking services(IPV6, QOS, etc), I have a few to test yet, but has not changed the behavior. I have also tried a different network adaptor on the Win 10 box, no change. I keep thinking its a config issue on the windows box, just have not found it yet.
Ok, itās clear that this is windows specific. Good.
The ānon-standard MTUā thing was my first guess, and @dannyās too. I know that RAAT uses ālargeā (4k) UDP packets, and if devices on a network have inconsistent ideas of how to deal with them (i.e. some devices fragment them, and some donāt) things like this can happen. For a clean test, all devices should have this feature disabled. But I think you already did that.
Iitās also clear that something more than just using Windows + RAAT is required to see a problem. We know that because Iāve been using Windows + SonicOrbiter for a few months on a daily basis (Win10+SOSE drives the headphones in my officeā¦all day, every day). About a month ago I switched that machine from 8.1 to 10, so both OSās have a good track record of high res playback, at least in my environment.
This is what my environment looks likeāRAAT works on this network from both computers in the diagram:
That it works on my network and not yours tells us that there is an environmental component to this problem.
From the logs, we can be sure that the app on the windows machine is sending packets.
From the logs, we can be sure that the app running on the SonicOrbiter isnāt receiving them.
We know that turning on Wireshark on the Windows machine hides the problem and allows packets to flow. This result suggests that this issue is related to networking, but it doesnāt tell us how.
Reliable failure after after a period of time (with no evidence in the logs other than dropouts) feels like some piece of network infrastructure trying to combat abusive or broken behavior. Like, it allows traffic itās uncertain about for a period of time, then starts blocking it, and the aggressiveness of the blocking depends on the packet volume.
There are two ways this ends:
- I reproduce the problem here somehow, and then debug it and develop a workaround or fix a bug.
- I (or someone else) makes a lucky guess and we figure out something that can be tweaked in your environment to fix the issue. That might result in an FAQ entry, or a workaround that we bake into Roon or RAAT.
@davezp25, @AgDev01, can you tell us more about your networks? In particular, do you have any hardware in common with @ComputerAudiophile? That might point us in the direction of a better ālucky guessā.
Very nice diagrams! 
Can you throttle that QNAP back a squidgen? Perhaps the Windows net commands are like filling 5 gallon can with a firehose.
Attached is diagram of my network. I have power line adaptors in place, but have removed them and replaced with cat5 to test, this did not fix the issue. Readynas is not used for music playback. iMac, not listed is wireless. It does not look like we have much in common save for the sonic orbiter se.
Hi @brian - I go back and forth thinking itās a network problem and thinking itās a different problem. I just removed most of my network for testing and still have the issue. Here is a diagram of my current testing setup.
The Netgear GS108 switch is dumb/unmanaged.
I even removed the network link to anything else on my network including Internet and NAS.
I stored all test files locally on my laptop.
The new network path is MacBook > Netgear switch > SOSE
Still the exact same issue.
The only other thing I can do is ssh into the SOSE and give it a static IP address, connect a cable directly from my MacBook to the SOSE and stream audio directly to it without a network.
This is starting to look more and more like a particular NIC and driver issue on the windows side.
On three totally different Windows machines?
I missed that part of the thread.
The only other thing I can do is ssh into the SOSE and give it a static IP address, connect a cable directly from my MacBook to the SOSE and stream audio directly to it without a network.
I like this test. Set up static IPs. Reboot the SOSE and the BootcampMac. See if it works.
Weāve seen evidence once already that the bad state is cached on the computers (after wireshark fixed things + switch was rebooted, things worked, but after computers rebooted things broke again). Static IPs let you reboot the devices on the tiny isolated network, which eliminates caching effects.
If that test shows the failure, then I can set up the same configuration here and attempt to replicate easily, since I have a windows machine, SOSE, and ethernet cable.
If that test does not show the failure, then you have a path forward adding elements back to the network one by one to troubleshoot the environmental cause.