RoonReady RAAT High Resolution Playback Problem [Solved]

And in my case it is specific to the Nuc. This


is playing this
and this
Just fine. No Chrome needed, will try Chome browser open on the Nuc

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.

  • Intel i210 Gigabit Ethernet adapter
  • Intel 82574L Gigabit Ethernet adapter
  • Broadcom NetXtreme Gigabit Ethernet (Apple Thunderbolt Ethernet adapter)

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.

2 Likes

Hi @Jesus_Rodriguez - Don’t steal my thunder for the article I am writing as we speak :grin:

2 Likes

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 :smile:

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.

8 Likes

Great to hear @brian.

Wow! This really goes to show the complexities involved in finding a bug.

Well done all.

SJB

Yeah, the process was enlightening and also surprisingly fun to watch - I was rooting for you guys when I went to sleep last night, and woke up to see the story unfold with a happy ending.

Fantastic job in finding this issue and brilliant that it will be fixed in 1.2.

Interestingly, whilst I do not play 24/192 at the moment (current DAC limited to 24/96) the insight into the issue has helped me too because on all music I DO get the 2 second jumping on the seek bar. I hadn’t mentioned it before because it was not affecting the music but it will great for that to be smoother.

That is awesome news!

Great work guys!

I can confirm that the issue is resolved in our setup as well.

Since I run Mac-only, I didn’t have this issue.
However, it was entertaining to see how everyone got involved, remained ‘gentlemen’ all the way through, and no rest was taken 'till a solution was found. Great team @Not_Roon, great community.

Hi Brian,

Just to add I got a Raspberry Pi with the IQAudio Dac this week (Running the IQRoon R2) and I get the same problem. At 22second HR audio drops out and the audio bar updates every 2-4 seconds.

I’m running the Core on Windows 7 (i7-3770K, 32Gb Ram)

Excellent news that you have already found the bug and have a fix in the pipeline.

Duncan

This is solved in the 1.2 release. Go check it out!

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.