DAC issues with XMOS usb chipset and Roon on Linux

It seems that Roon could mitigate this issue by not upsampling MP3s to 44.1/24, but perhaps to 48/24? Do I understand that correctly? Until DAC firmware upgrades arrive for the various XMOS DACs.

You’re playing something with 44.1K on 24 bits, which works. After that you’re switching to 44.1K on 16 bits, and then stuff breaks down.

Hil Bill, I’m not brian, and obviously not answering for him.

But this XMOS bug isn’t limited to MP3’s though. If someone really wanted to do any custom sample rate conversion, you can already do this yourself manually now, here:

@Bill_Janssen, no not quite–the trigger is transitions between 16/24/32bit, not 44 vs 48. And this is not MP3 specific either.

Remember that this affects some DACs, not all, so any mitigation would have to either detect those products or add a user-facing setting to let people opt in. The former is somewhat difficult and the latter is generally distasteful as a product design choice.

It’s much cleaner for the world, and better for everyone long term, if the DACs have their bugs fixed. If we patch around every DAC bug, it disincentivizes manufacturers from doing the right thing.

We now know that this issue is timing sensitive–so a player that is just 1/10th of a second slower than Roon at switching sample rates is unlikely to encounter the issue. This is likely why reproducibility varies so much from system to system (at least, in our testing, this bug is variably repeatable. Some systems can repeat it as much as one out of every 2-3 transitions, and some need 100 transitions before encountering a failure).

By the way, in offline discussions with partners, we have been relayed user reports of this issue affecting MPD and other players…which is to be expected given the technical understanding linked above.

For personal mitigation, you could set up a procedural EQ with 2 gain blocks that cancel each other out. That’s the closest thing to “nothing” that will also force the 16->24/32 conversion, I think.

We’re going to see how it goes with the manufacturers before deciding how to proceed on any possible mitigation efforts here. They all entail work, long-term compromises, or both–whereas DAC manufacturers should be happy to apply the straightforward fix outlined in that thread + spin new firmware without any of those downsides once the issue is brought to their attention.

While I understand the appeal of this approach, it doesn’t account for vendors of abandonware. That’s all too common in the tech world. Take the Project S2, for example, where differences between the designer and the manufacturer resulted in the designer leaving and now the S2 will basically never have another firmware update (other than the one the designer said they MIGHT consider making and selling directly themselves). I know the S2 is XMOS-based, I don’t know if it suffers from this bug, though.

As far as I can tell - it does. Mine has locked up quite a few times. It is only seeing this thread that made me realize it does indeed seem to happen when switching formats. I have had it happen when fiddling with Roon’s DSP as well (enabling, tweaking, disable - which I guess would switch it through 16, 32, 16, or 24, 32, 24 etc).

The best we can do is to start being somewhat more forceful with Pro-ject support. I have seen John Westlake become quite vocal and public in defending issues with this DAC, so I guess that places him in the firing line for support as well.

As it stands, this issue not withstanding - it does also need an update anyway to put a final end to MQA dropouts on Linux devices. We should not be the ones to suffer for this just because they cannot get their business dealings in order though inadequate project and/or risk management or whatever.

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