DAC issues with XMOS usb chipset and Roon on Linux

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

I"m not sure why you just don’t use windows on the NUC and then plug in the Liberty, a lot cheaper than a Rendu. I and many others have used Windows as the OS for RoonServer for years and it has been rock stable (pun intended).

It’s also worth noting that Linux/ALSA USB difficulties with different DACs, and not only those with XMOS USB receivers, have popped up for quite a while here and in other forums. My suspicion is that the Linux USB audio stack is written in a way that is more likely to push some USB receivers out of their well-defined states. There could be bugs on both sides (likely given the complexity of the USB audio protocol), there could be poorly specified parts of the protocol interpreted differently by different developers (likely for the same reason), or there could be optimistic hardware timing assumptions in USB DACs that the Linux stack does not conform with. I have experienced directly frozen/distorted play with USB audio ever since I started using this kind of gear, which is is one reason I have no USB in my 3 audio chains currently, although I still have a USBridge around to play with.

3 Likes

@Rugby Great question. I was attracted to the appliance aspect of ROCK on NUC. No OS to maintain, super simple management console, and automatic updates. I already have enough “things” to maintain around our home.

The Rendu has it’s own benefits. First it allows me to put the NUC in with the rest of my network gear, plugging directly into my core. Secondly, the Rendu along with its linear power supply has a very low noise floor, lastly it sounds better to me than a direct connection. Factoring in the cost of Win OS and my time vs Rock on NUC and a microRendu with its added value, for me at least, is a bargain.

1 Like

Hi all,

just having issues setting up a Sotm DAC-200HD with Fedora 23 and Roon. The same hardware previously played no issues with the SoTM, but was a much older version of Fedora and using LMS, but with the new OS & Roon or LMS there is no volume.

The DAC is identified by Roon and the OS, and the stream “plays” but no audio is heard.

The same DAC and windows is no issue, and I had an M2Tech, Lampizator & old bushmaster DAC working OK with the same server and Roon no issues. So just the SoTM with issues.

Looks like SoTM use an xmos XS1-L1 chip.

Does anyone know if SoTM are on the list of listed manufactures with issues? I know the symptoms I am having are different to the thread, but there’s a lot of commonality. I have email SoTM but no response yet.

Has anyone been through the xmos site Linux driver recommendations?

https://www.xmos.com/developer/published/enable-usb-drivers-linux

Wondering if that might help.

@support can you please point me to the current position on this? The thread is long and old and I don’t want to misunderstand. What I get from this is that:

a) DAC manufacturers must fix the XMOS bug on a case by case basis
b) One workaround is to use a Windows core
c) Another workaround is to selectively upsample in roon

Currently I am not affected by this as I use a Windows 10 core which is just as well because I have a favorite long-discontinued XMOS DAC so a) almost certainly will not work for me and c) looks impractical as I have a lot of varied content and like to use radio / shuffle / playlists.

However I am now planning two major upgrades.

  1. I am migrating my core to a NUC and wanted to use ROCK
  2. I am adding a new endpoint/dac with an XMOS USB interface (Mark Levinson 5101). It also has an ethernet interface.

and

  1. I want to keep the discontinued XMOS DAC but I currently use it via ethernet (SoTM SMS-200 Neo)

My question is. Can I do any of this? Just use ROCK/Ethernet and avoid USB. Or has nothing changed and my best bet is to continue using Windows on the NUC?

1 Like

Hello @Tony_Casey,

We implemented a mitigation for this issue in RoonOS / ROCK in early 2019. While we cannot guarantee that this mitigation will resolve the issue in all cases, for the majority of users it has successfully prevented the XMOS bug from being triggered.

-John

Thanks for the quick response. I hadn’t followed the story because at the time I wasn’t affected but now I will be. Fingers crossed.

Now, if God exist and the allmighty carrier of my precious new China audio device do their work, I will off course be facing some new challanges shortly.
It is a Breeze (exist under several brands including the very popular Audiophonics, remember?) USB XMOS 208 to AES-EBU (AES3) converter, self-powered from mains, asynchronous operation and seems pretty well built besides that the protective earth line is not connected inside along some other typical China features rendering the buyer the mandatory DIY status.
Besides that, I plan to connect this to the Intel NUC I have with ROON R.O.C.K. using the NUC USB interface. Now, after not having the time of reading through two years of clever thoughts and brilliant ideas, I thought I just ask, will an USB XMOS 208 receiver chip be recognized by the excellent R.O.C.K. on Linux USB output? I truly hope so, the almost zero level of hardship from current config is sooo soothing.

Hi, just adding the product for your knowledge. Am I able to hope for some sort of integration between a device lika the linked, or should I just go for the windows Roon core, instead? I do not want to, though. I think the R.O.C.K. rocks … Sounds just fabulous.

@Computer_Audioholic - That device appears to be a way to add USB to a non-USB DAC. For example if you wanted to use a computer to output audio to a DAC but the DAC didn’t have a USB interface.

There are a few companies that make devices like this such as Singxer and Gustard. I use a Gustard on the USB output of my nVidia Shield. The Gustard outputs digital coax which then goes to my headphone amp/dac for night-time listening.

Indeed it does, and for anyone wondering, the ROON R.O.C.K. integrates perfectly, addressing the Xcore. Since My DAC’s integrated in my studio monitors, offering the output AES3 to be daisy chained between each speaker and sub woofer, it has so far proven to be a substantial sound quality boost.

Given the circumstances I have, I would recommend anyone who will not replace a well sounding DAC, but have AES3 available and want to figure out the XMOS chip contribution, to try this one out. But also have in mind I have modified mine a lot. There are in my opinion some really sloppy design flaws.

Not using Roon but had an issue with Linux playback into DAC with XMOS receiver.

Basically on attempting to play a track (even at the lowest level with aplay), the DAC would disconnect from the Linux end point.

Tracked it down to the USB 3.0 stack in Linux (i.e not related to ALSA or pulseaudio as I remove the ugly hack that pulseaudio is from my Linux image).

After trying hardware based solutions like using a USB 2 hub , I bit the bullet and hacked the Linux source code***, removing the USB 3.0 stack, recompiled the kernel and installed it.

Everything runs perfectly now.

Know this doesnt help Roon users but failing any patch from XMOS, it was the only way I could retain my investment in my expensive DAC.

Peter

*** as a retired Unix/Linux system level programmer, removing the USB 3 stack was a fun little project given how critical the USB stack is to any OS.

1 Like

Does your issue involve bit depth changes? Is the symptom exactly like “if you play music on Linux based hosts and go from a track with a certain bit depth to another one, the system would hang. A short white noise like sound is to be heard, after which the host looses connection with the USB stack”?

Did a USB 2.0 hub successfully workaround the issue you had?

Does your PC hardware have a USB 2.0 port?

If you ran into the same XMOS bug in this thread, do you have any idea why USB 3.0 stack make a difference?

What does this involve? Changing config file(s)? Modifying a bunch of source code?

Personally, I have always found recompiling from source a satisfying and rewarding thing to do. Kudos!

(1) the issue may or may not have involved bit depth change.

In my case, once the OS had booted and I did an “lsusb”, I could see the DAC but when I started playback it would disconnect.

dmesg showed "EPROTO 71 / Protocol error /" as the reason

So it might have been a bit depth change issue. All my files are 16/44 so if the DAC connected at some other rate (internally its 24/96) then yes it would involve a bit depth change.

I will see if I can determine what bit rate my DAC defaults to on connection but I assume it is 24/96

(2) No, using a USB 2 hub didnt help.

Forcing an intermediate change to USB 2 via the hub still meant I was ultimately going through the xhci receiver on the motherboard, which as we will see below, was my issue.

(3) Does your PC hardware have a USB 2.0 port?

Yes, ultimately as discussed below.

What pushed me to a solution was I had an old desktop PC with only an ehci (aka USB 2) USB controller which worked fine but my new target PC (a small compact NUC like ASUS PC) only had xhci (aka USB 3) controllers and it didnt work.

So the issue was with the USB 3 stack (or its interaction with the XMOS receiver).

I also had in my stock of PC’s, some fanless, small form factor Gigabyte Brix PC’s that had both ehci and xhci controllers and using this command 'lspci -nn | grep USB | cut -d ‘[’ -f3 | cut -d ‘]’ -f1 | xargs -I@ setpci -H1 -d @ d0.l=0" was able to force all xhci connections over to ehci and all worked fine.

But my ultimate end game was for my end point to be a diskless client that booted into ramroot off a USB stick but when the running ramroot image had the above command run, it all turned to custard as the OS still needed to see the USB stick and the forced USB stack change knackered that.

So I needed to hack the kernel to get to my desired end state

(4) What does this involve? Changing config file(s)? Modifying a bunch of source code?

The change was ultimately easy enough.

There as no guidance from “Dr Google” so I just went into hacking mode. In the end I just needed to change some header files and some config files to force the kernel build to not include the xhci stack.

I obviously wasnt sure if, even after a clean compile, that Linux would boot and run ok, but it does.

(5) NOTE: VERY IMPORTANT.

My use case [where I wanted to boot ram root into a small form factor PC AND connect to my DAC via the XMOS receiver AND remove the offending compatibility issue between the XMOS receiver and the Linux USB 3 stack (proven to be the issue on two different PC’s, as noted above, with ehci only and ehci/xhci motherboard chips respectively)] only works because my now target Brix PC*** supports both ehci and xhci.

Running the hack on say an intel NUC with xhci only means you end up with no USB stack.

So all I was trying to point out in my orginal post (without all the nasty details) was that my issue (which might be bit depth related) has conclusively related to the USB 3 stack/XMOS receiver interface.

*** I have three of these so I have enough spares to keep my current setup valid until I change my DAC

Assuming this is still an issue for people, if you can provide me with a simple test case (rather than me having to read the whole thread) I am happy enough to come out of retirement and see if I can provide a solution that works with xhci controllers or whatever the root cause is (assuming it can be resolved from the Linux side)

Aside from the test case, what logs do you have?

For, example, what does dmesg show when the issue occurs, so I can ensure the test case I run produces the same error.

Does this forum support PM’ing people? If so and you want me to have a look, PM me so we can exchange email addresses.

My dev lab was/is in my house (connecting from Down Under into the US Mothership was too cumbersome), so I still have tons of hardware lying around, not only intel PC’s but also solaris/aix/hpux servers (not that they are related to this scenario).

Peter

PS. I have run Roon in the past, with LInux as the endpoint, so am familar with using Roon