DAC issues with XMOS usb chipset and Roon on Linux

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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

Very well said @Bart_van_der_Laan and thanks for sharing the fix and your thoughts.

1 Like

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.

It’s kind of patronizing to argue that the CTO knows his company priorities less than you do, right? Perfectly reasonably to be unhappy with a product and vote with your wallet, but presuming to understand the details of the company’s internal dynamics, priorities, and revenue model seems rather grandiose.

@brian won’t quite say this, but I will. Multiple streamer and DAC vendors behave like leeches, taking advantage of open source and standard firmware, doing the minimal nameplate engineering, and putting out poorly tested products without any plans to support and upgrade them. It’s unfortunate that users were taken by those vendors, why should Roon or other music software vendors pay the price for that unhappy blood sucker/blood donor relationship?

3 Likes

i have just asked LH labs if they intend to fix the bug for the geek out v2 DAC … lets see what they have to say.

Phil Kemp

Point taken. You are right. I will assume that the CTO does know what the rest of the Executive Team is thinking. Which could only mean that they also know and agree about this poor decision. Thanks for pointing that out. I was trying to be optimistic.

Pretty sure Mojo uses an Atmel ARM decoder not XMOS decoder?

I know Hugo1 and Hugo2 use an Atmel decoder…

Looks to be the same for Mojo (Mojo photo below) but I’ll double check and come back here…

Mojo is infamous for being buggy - a bit less so on Windows with Chord’s ASIO driver but I’ve had issues on Windows too… sudden bursts of static on Windows too… My Hugo2 much much less buggy.

I was intrigued by your post and pulled out my 10 meter Corning optical USB3.0 cable to connect my Hugo2 to ROCK and I don’t have any issues.

I’m not saying you might have jumped the gun here but I would hold fire a bit and triple check the Mojo issues you are experiencing are definitely related to this XMOS bug discussed in this thread…

2 Likes

Confirmed by Rob Watts - Mojo doesn’t use an XMOS decoder…

https://www.head-fi.org/threads/chord-mojo-dac-amp-☆★►faq-in-3rd-post-◄★☆.784602/page-2534#post-14711092

1 Like

This confirms my suspension. I personally didn’t have any issues with Roon on Win10 Pro and the Mojo feeding my Pre. I only began to have issues when I switched this setup to ROCK on an i7 NUC.

In my office I have a Mojo attached to a Win10 laptop as an endpoint and it works perfectly. It makes for a very nice office setup. That and a bit of vintage Marantz Gear :wink:

At this point with the minor headroom change in place there’s not much more for me to do other than getting an external power supply for the Liberty and perhaps another Sonore microRendu. After that I won’t mess with this setup for 18 months or so and then I will trade up the DAC. In the meantime I am going to rebuild an LP12.

Cheers!

1 Like

Excellent stuff Vincent.

Just needs a “sorry Brian” on the end :grin:

5 Likes