The endpints are not the issue it’s the DAC attached to them. If it uses the XMOS chipset for USB implementation then it may be susceptible to it. But not all DACs seem to suffer from it.
USB DACs are not Roon Ready only RAAT enabled endpoints are Roon Ready. USB DACs are Roon tested. Roon tested USB DAC could in theory still have the issue, especially since it’s only become more apparent/evident as an issue with more recent updates to Linux in ROCK.
@CrystalGipsy - what I was hoping is that the very nature of an ethernet endpoint, like an ultraRendu, would add enough delay to give the DAC the 1/10 of a sec we are missing on the interface.
The Rendus have been patched to work with the Mytek Liberty as I recall. Have you tried using that with the Liberty?
Edit: Or that might have been regarding Native DSD output. I’ll double check.
Unlikely, as this is happening on ethernet endpoints connected to DACs via USB.
@Rugby - I am going to move my microRendu tonight to the Liberty. Currently attached to a Sony TA- ZH1ES and I haven’t noticed skipping. But, that amp doesn’t get a lot of Roon time.
How about inserting a USB reclocker between the ROCK and DAC?
Something like:
Might work. As I said earlier, I just switched my RoPieee box from Ethernet to WiFi, and that changed the timing enough.
I’ve requested a manufacturer of a reclocker to run some tests. I’ll post what I learn.
Testing results:
Unfortunately the reclocker did not solve the problem. Turning on DSP with everything disabled except the Headroom adjustment and set that to anything but 0 (-0.1db) the problem is resolved and you still get bit perfect playback. This adds another layer of the Roon engine that somehow resolves the XMOS to Roon issue.
Clearly not the final solution, but, better than getting told that the rest of the world is the problem and not Roon.
6+ hours now into a playlist which multiple different formats including MQA. No issues so far with the DSP setting enabled (everything disabled except the Headroom adjustment and set that to anything but 0, I used -0.1db).
Thanks to the community for all the work you’ve done to uncover and work on this issue.
Roon Team - I’m pretty certain you can guess what I think about your prima donna attitude.
Interesting. There was another issue I seem to remember that was corrected employing a similar solution. Too tired now, but, curious enough to search the forums tomorrow. Glad you got it worked out.
Which of these are you referring to?
I suppose all of the above are fixed and no longer required?
Hi,
Thanks to all who have reported this issue. Since I am the one who discovered and fixed the bug, I feel entitled to share some thoughts and opinions in the matter hopefully without offending anyone.
-
Roon is not to blame for this issue. Period. Asking them to implement a workaround is like putting a band aid on an infected wound. As long as the root cause of the issue (mind you - one line of XMOS code) is not fixed there is no point to it.
You can also look at the bigger picture; Just imagine that every company providing Roon-like streaming solutions with USB playback must implement such patches to cover up underlying issues…No Go.
Think of it as an ever-present hidden bug that has surfaced in the field with evolving use cases because the part of the bugged XMOS code is now being addressed more often. Different behavior is seen on different platforms because they use the same system in a different way. Which means other platforms can encounter this issue in the future just as likely. -
I have noticed some of you have magically sympathetically reasoned towards a timing issue or even brought USB compliance into the equation. Again, one simple line of code causes the XMOS stack to crash because it tries to read and write in an illegal memory region. This action takes place in a section (which is indeed part of the USB audio framework) where the XMOS stack is asked to switch bit rate. No magic involved.
-
My hat off to the XMOS team. They have provided hundreds of (small) companies with a superb software reference design to derive their own implementation from with a relatively spectacular low investment of time and money. Countless lines of provided code working flawlessly to stream your favorite music with one line missing – Sue Them!.. Not.
-
My biggest concern is for the people who have bought products from companies that implemented the XMOS technology in a me-too product that lack the desire or ability to fix this simple issue in the field. Some of them might even rely on a third party to fix that for them.
To anyone who encounters this issue, contact your product vendor. If your vendor states its device is not supporting Linux, they are hiding and hoping for the storm to pass. Good riddance to manufacturers who do not stand behind their product, especially when the (not so easy to find) solution is spoon fed to them. In case one of these vendors is willing but incapable of implementing this fix, they can contact me to see If I can help them out.
Cheers,
Bart van der Laan
Kii Audio
18 Likes
I believe it was @brian who originally brought up the timing issue:
I myself wonder if there aren’t multiple bugs here, the one that you found, and perhaps an issue with the Raspberry Pi missing USB interrupts when both the USB port and the Ethernet ports are used simultaneously. There’s some things on the Pi blogs which make me suspicious of this, combined with the fact that my moving my Pi from Ethernet to WiFi has suddenly removed the occurrence of this without changing the DAC software – previously very repeatable with the Ethernet connection. Though I think if this were the case, we’d be seeing more evidence of it.
See the xcore link above dated Feb 8, 2018.
@Bart_van_der_Laan - You are completely missing the point. This isn’t some purist search for the perfect USB interface. This is about customer service and compatibility in the real world. Roon is a tiny player in a sea of competitors, many which are considerably larger with a lot of depth, a lot of resources, and a clear understanding of customer support.
While I totally dig your post, it doesn’t address the basic issue of customer service or sales. No dealer in their right mind is going to support a product whose compatibility is tenuous at best. Who would want to take on this burden from a support perspective? There’s no readily available listing of compatible DAC’s. Expecting current or existing users to attempt to learn if a DAC vendor uses XMOS is laughable at best. Have you gone to a vendor website and tried to find this information? Even if they posted this info, would information on how it’s implemented be available? If I wanted to know this information about your gear where would I find it? Doesn’t your Kii Three have USB? Realizing that the Kii Three is not involved in this, but, as an example, how would I know what tech you’ve deployed inside the box? How much research are you expecting the average hobbyist to do? Write you? Call you? Dig through your site hoping it’s posted somewhere?
For me, this issue, and Roon’s response, puts their long-term viability in jeopardy. Users with pre-existing DAC’s may have issues as well as unsuspecting new users who purchase new DAC’s. It’s the 21st Century, word spreads quickly. What happens when an Audiophile reviewer from a mainstream publication runs into this issue and publishes their findings and Roon’s opaque response? As a perspective end-user I would have second thoughts about adopting this product after reading that in the press.
I started out with a Windows host and a Chord Mojo as a proof-of-concept. It worked really well. But, I wanted the stability of an appliance so I migrated. The moment I switched to ROCK on NUC my issues started. If this issue existed during my proof-of-concept I would have never proceeded. As far as I can tell Windows hosts don’t seem to have this issue. I may be wrong, but I haven’t seen this phenomenon addressed in this thread by the likes of you or @brian.
Do you or @brian think that this tiny company is going to influence the dev cycle of every single DAC manufacturer on earth? And even if you could, those cycles aren’t immediate. While you are out attempting to get these vendors to agree with you and get this issue in their Dev cycles, the slow poison of bad press, bad dealer and end user experience will erode any credibility that Roon has developed. It will become vaporware.
Wow, but you’re melodramatic.
I stand behind my comments here with digital ink or in person. The more I think about it, my guess is that @Brian hasn’t discussed his stance with either Marketing or Finance. He is clearly willing to jeopardize revenue and market viability for his own need to be right.