Here is some info I haven’t seen with this issue until now- I reproduce the 20 second issue over and over. I clicked on Chrome to check the diag and before I could refresh music started playing. I click back on the Roon window and about 20 seconds later the audio stopped. I clicked back to Chrone and the audio started working. I clicked back to Roon and the audio stopped about 20 seconds in.
This could also explain the wire shark thing.
Some additional follow up. Playback is improved but far from perfect with what I described above.
OK. Let me describe what I did. Maybe there’s a difference I’m not spotting in our setups:
This is really weird. My Windows 10 machine is very fresh as well with a new copy of Roon and some local 192 content. You went through the same stuff as I did, but achieved a different result.
I can’t think of any other variables or things to try.
Was Roon the active window while you were playing music?
Yes. The only window in fact.
I was going to say “maybe my SOSE is different than yours”, but I remembered that this affected Aries, too, so it pretty much must be on the windows side.
I have another guess, in part based on the last thing you said.
Maybe this is power management stuff.
And maybe my Windows machine (which is a few years old, and a very desktop-y machine) isn’t capable of misbehaving. I have a spare brand new 6th gen NUC here. Maybe I should install W10 on it and see if I get a different result.
What power management plan are you using? If you change to “High Performance” does it have any impact?
I have it set to high performance.
Going with the idea that my windows machine is somehow immune to this problem, I dug through the gear pile and came up with a ~2013 HP Laptop that had Win10 installed already. I figured it would be quicker to test there than to do a win10 install on a fresh machine.
This laptop is having the same problem you are. 192k playback fails at 20s. Opening Chrome “fixes” it.
This is the greatest thing I’ve heard in the last week. Honestly. I was ready to call it a day/week/year and resign myself to a RoonReady-less network.
And in my case it is specific to the Nuc. This
I’ve been so fascinated by this troubleshooting session I went to buy a SOSE for myself. But they are sold out…
It has to be related to certain NICs on windows machines. What else could it be?
I just checked all three NICs and can’t narrow anything down further.
Hmmm, I was hoping it was all something other than intel NICs.
Did you ever try putting your macbook pro on wifi instead just to see if it was still an issue?
Also locking NIC at 100mbit/sec instead of gigabit? Or maybe it’s not an option with the thunderbolt adapter.
I have done both of those suggestions on my nuc. It does not appear to make a difference.
Some food for thought while the Roon team looks into this issue. When we build all in one units or Chris builds a new CAPS unit quite a bit of research goes into selecting hardware and software that works well together. I can’t speak for Chris, but I have had my share of hardware that didn’t work as expected in my boneyard. Hardware that otherwise worked great for friends who took the parts home to build gaming units. It’s hard for one software to work on all the Windows clones that exist out there because the number of permutations on the hardware and it’s accessories are infinite. This is the reason why Roon has the RoonReady certification program. The RoonReady certification program assured the end user that at least one of the variables has been tested and vetted for use with the system. Should a problem arise they also have a record of the unit to test on and validate fixes. The Roon team is top notch and now that Brian can reproduce the issue in the lab it can be properly addressed. This is a great testament to the Roon team’s commitment in developing their audio eco system.
We have a fix for this issue prototyped.
The fix will be in the next Roon update. No device firmware updates will be required.
The device that struggled to play 192k audio for 20 seconds has been playing DSD256 for the last half hour.
We do want the fix to see some testing before dropping it. We are putting our 1.2 release into alpha testing this week, and it will definitely be on that “track”.
Despite how the problem appeared at first, it had nothing to do with networking at all. It was related to the behavior of the OS’s scheduler (i.e., a Zebra).
Some background
When Roon is sending audio to RAAT devices, it’s a david+goliath situation–the machine running Roon is capable of flooding the smaller device with packets at a rate that would overwhelm and result in lots of dropped packets.
This is only really a concern at the start of playback, since at that time Roon pushes a few seconds of audio into a buffer on the device all at once. Obviously, we want this to happen as quickly as possible, but if we actually sent the packets as fast as the PC is capable of sending them, half of the packets would fall on the floor because the PC is so much faster than the device.
So Roon has an internal rate limiter. The rate limiter is running all the time, but normally only affects what’s going on before playback starts, since the limit is much higher than the bitrate of any audio stream.
The Bug
On Windows machines, the implementation of the rate limiter was being influenced by the behavior of the OS-level scheduler in a way that we didn’t anticipate.
We went back and measured on Linux and OSX and the scheduler influence simply isn’t happening there.
On my “good” Windows machine, the rate-limiter is affected by the scheduler, but the influence is at a much lower level, so it doesn’t impact playback.
On my “bad” Windows machine, the problem happens just like it does for you guys. But–when I open Chrome, the measurements begin to look a lot more like my “good” machine–for a little while.
I have conjectures as to what is going on under the hood and what detail makes the machines different, but I’m not certain enough about my ideas to guess out loud. The important thing is: we have a new rate-limiter implementation that doesn’t have this problem, and we’re moving on 
The bug also had a secondary affect–it made updates to the seek-bar choppy. So you’d see the seek position skip by 2 or 3 seconds at a time sometimes. That will be fixed going forward, too.
Thank You
Huge thanks to @ComputerAudiophile and everyone else who helped out by providing information and trying things out at home. You guys helped us narrow down a wide field of potential explanations into something narrow enough to reproduce and fix quickly.
And thanks to everyone for your patience while we get this release stabilized and out the door. It’s a big one, but it is shaping up very nicely.
