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.