DAC issues with XMOS usb chipset and Roon on Linux

So we are likely in the hands of the Manufacturers, I wont hold my breath of getting a quick update considering the last one for mine was 18 MTHS ago so this issue must have been around then too. I was
using spdif until June this year though so would not have noticed it.

I didn’t say we definitely wouldn’t do anything here–but I do want us to contact manufacturers first and see how it plays out before making that decision.

The age of hardware products as unchanging artifacts is over. We are living in a world where no-one should be tolerant of companies who release connected products without a plan for long term updates/support. Whether it’s about compatibility, security, bug fixes, or simply delivering more value over time, the availability/commitment to delivering software updates should be taken into account when making purchases.

Apple, Nest, Tesla, Sonos, and countless other brands have cemented this as an expectation in consumer electronics today. Clearly, this is baked into our philosophy too, with both hardware and software products. To the extent that we can push manufacturers to “get” this, we will always try to before doing the “bad” thing and working around their problems.

To be clear, I am not criticizing any particular brands here. We haven’t reached out to anyone and gotten a “no” yet or anything like that. This is all just general commentary right now. We will be reaching out to people soon.

3 Likes

I was referring to this line in the link you posted:

So for example switching from a 44.1k/16b to a 48k/24b is no problem, but if the sample rate stays equal; (for example 44.1/16b to 44.1/24b) you will get this bug.

So, it’s when you switch bit depth, but keep sample rate the same. Apparently Roon presents low-res content as 44.1/24 based on this bit from Simon:

It tends to happen more on low Res content that Roon itself automatically upsamples to 44.1/24

I don’t know enough about MP3 to know if it’s actually possible to present it at a different rate, but I’m assuming the majority of user’s tracks are either MP3 (or other low-res) or CD, and making sure they don’t use the same sample rate would alleviate the problem some during the couple of years manufacturers will surely take to update their DACs, without having to waste time sleeping.

Definitely a timing issue as well. I can use a Mac Mini 4,1 running Ubuntu to drive the USB connection, and the problem doesn’t happen. I can replace that with the Pi/RoPieee box, using the Ethernet connection, and it happens. I can switch the network connection of the RoPieee box to WiFi instead of Ethernet, and it stops happening.

Looking at the Mytek Liberty firmware updates changelog, I see this in the latest version:

Fixed issue with fast changes of sample rate and signal source

Wonder if that’s the change they’re referring to.

Try it and see.

I’m already running 1.31, so if that’s the change, it doesn’t work so well.

Oh well, must be something else

I have exactly the same problem with my installation : an antipodes server dx generation 3 with roon connected either on a dac oppo ha-1 or a dac icos dactablette 5. These two dac integrate an xmos chip. My solution to use roon and usb output : set roon by activating the volume control by the roon application. An other solution is to adjust the maximum bit PCM to 16.

Note that I do not have this problem using a dac sotm ex-usb hd.

Have you heard anything back about this?

Hi to all

I have the same issue with my NUC / ROCK connected to the USB card of my DeqX HDP 4 (Xmos based). I did not noticed if it was because of a file bit depth change, but I heard a ´pchiiiitttt’ and music stopped but not Roon. I had to hard reboot the DeqX device to have the system back but only for a few minutes before a new ´pchiiittt’…

I never faced this issue with Daphile running on the same NUC and same DeqX HDP 4 USB entry. It is OK since beginning of 2017.

In addition, there is no problem using the DeqX Spdif input throughout a Raspberry pi 3 + Allo digi one and Ropieee.

If this can help.

Phil

We’ve been in touch with seven brands about this.

One is supposed to push a fix this week. Another has acknowledged that they are working on it. Four more acknowledged our communication but didn’t start work, and one hasn’t replied.

Thanks for letting us know about DEQX–we will reach out to them today.

I’m using a Khadas Tone Board with RoPieee and seem to be having this issue. Is there any chance you could reach out to them?

Hi Brian

Just tested ROCK again tonight with my NUC 6i3 USB interface and got the same ´pschiiiittttt’ after 15 minutes using the USB XMOS input of my DeqX HDP4… Never had this problem with Daphile since 2017/01… I don’t think this is due to XMOS implementation with DeqX neither DeqX firmware update, but there is something wrong with ROCK Linux implementation…

FYI, no issue at all with RPi and DietPi + Roon using USB.

We have a pretty thorough understanding of the issue…

  • Original bug is in the XMOS implementation…there is no controversy about this at this stage. That bug has been around for a long, long time, and likely impacts quite a few products.
  • When you combine that XMOS bug with a new enough Linux kernel, this bad behavior is exposed. This part seems to be because newer Linux kernels perform better, and this bug is timing related, so with newer Linux, the DAC is asked to process commands faster, and this trips it up because of the XMOS bug.

The second factor–i.e. that ROCK is using a newer version of Linux which performs better–is not a fault with ROCK. It is just a fact of life in a world where things keep moving forward. If the Linux kernel were broken, we would have fixed it long ago…but we’ve investigated, and it is totally compliant. This is also why ROCK is different from some other Linux stuff you may be using. We are better at keeping up to date, and flowing the latest performance improvements into our OS than some others.

I’m not sure if you’ve the homework required to make the conclusions you’re making. I’ve read the XMOS code, and the Linux code, have experimented with the timing characteristics that expose the bug, and understand it thoroughly and personally as an engineer. I also am the architect behind RAAT and ROCK and understand clearly which part of the system is responsible for what. You’re challenging the wrong guy on the technical facts :slight_smile:

If this bug were ours, we’d be all over fixing the code. That would be the best case scenario, because we would be in total control of the issue and no longer talking about it–But it isn’t ours. Of course, we are still all over it, coordinating communication with manufacturers, explaining the technicalities so they know what to do, etc, in an attempt to get this fixed for everyone.

The only thing we can’t control here is how quickly they move. If you’re concerned about a particular product, reaching out to the manufacturer can only help them understand that this is important to you.

5 Likes

Brian thanks for the work you’ve put in to understand this issue and relay it to the manufacturers affected.

I have the exact same issue you all are describing with my Mytek Liberty DAC running firmware 1.31 (latest available) connected to Roon via a wired Ethernet Pi3 running Ropieee.

I described the issue in a ticket to Mytek and they responded saying that Linux is not officially supported and that I should plug it into Mac or windows and see if the issue repeats itself.

I investigated further and changed the resync delay setting to 50 ms in Roon to see if that improves the situation and allows the DAC more time to switch formats. It seemed to improve but it was only a matter of time and it started happening again.

I’m frustrated that Mytek isn’t officially supporting Linux or fixing this bug.

If you have any thoughts on how I can approach this with the team at Mytek I’m all ears. Thanks again for the effort you’re putting in.

Zaid

Unfortunately, resync delay puts the delay in the wrong spot…so it probably will not help with this. With resync delay, we send some extra silence to the DAC after the format change, but at that point, the problem has already occurred.

We have a close relationship with Mytek. I will make sure we reach out and let them know that “use windows or mac” is an unsatisfying answer to be handing out to people.

3 Likes

If you’re referring to this:

That doesn’t seem to refer to the bug as I understand it. It occurs with fast changes of sample depth without changes of sample rate, and without changes of signal source. So maybe there’s a similar but different bug which was fixed in 1.31.

Oh. Yup I think you’re correct there Bill (and the playback issue that still occurs is further proof that it’s a different issue than what they fixed in latest firmware update). Glad to know I’m not the only one up late thinking about these things :nerd_face:.

Happy Holidays
Z

Hi Brian

I do not have your experience and I am not judging it. But I am a user of various LINUX distribution for years. And as a user, I can just attest that they are all working fine with the same NUC and the same DeqX XMOS USB input except ROCK.

I fully understand the mean to master your own distribution which makes ROCK a better and different product compared to others. This is a good product strategy, but the result is that it is not working fine with some XMOS USB inputs of your customers.

To my opinion, it is a bit “easy” to say ROCK is good and the problem is elsewhere. As a product, ROCK is to be compatible with those wrongly implemented XMOS hardware and should propose a way around event if it is less perfect. Can you imagine your car dealer saying your engine is working fine with unleaded fuel except the one of some fuel stations?

Don’t make me wrong, ROCK seems to be a good product and ROON is a good product. But a slight move to be more compatible would be much appreciated.:heart_eyes:

— Edit
By the way, I sent an email to DEQX support team. Hope this will help.