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?
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.
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…
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
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.
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.
@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.
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?
@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.
I am migrating my core to a NUC and wanted to use ROCK
I am adding a new endpoint/dac with an XMOS USB interface (Mark Levinson 5101). It also has an ethernet interface.
and
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?
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.
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.
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?
