There seems to be a growing number of support threads all relating to the same thing. Roon is hanging the DAC when bitrate switching. It only seems to effects endpoints running Linux and the DAC has the XMOS usb chipset. This can be endpoints running Roonbridge on dietpi, Ropieee, Rock and even the Nucleus itself amongst others. Its been ongoing for months now. I myself have had to mention this on a lot of threads that this keeps coming up on, I have lost count of how many but it’s been 3 in the last 24 hours.
The only current work around seems to be to upsample the content causing the issue or just upsample everything. It tends to happen more on low Res content that Roon itself automatically upsamples to 44.1/24 but CNA happen with regular 44.1/24 and more so when it switches to it from regular 44.1/16.
It also is Roon specific as other players running on same os and hardware do not experience the same problem.
I have had this issue with my Arcam irDac ii with Allo USBridge and Raspberry Pi running Ropieee.
It would be good to get a statement of this from Roon as to what’s being done to look into it and also feedback from the community. @brian can you comment at all.
We just laid hands on a DAC with this issue for the first time a week or two ago. Then QA reproduced the issue, and transferred the unit to my location a couple of days ago so I can look into it.
Initial impressions suggest that the problem traces to how a newer version of the XMOS firmware handles bit-depth changes between 16 and 24/32bit formats. Based on what I have heard so far, this doesn’t look Roon specific, rather that Roon is a little bit better than most other players about using the most compact format possible, and this means that devices are switching format more often with Roon and thus are more likely to encounter the bug.
Hopefully we can figure out a workaround. Won’t really know for sure until I dig into it. It will be looked into before our next release.
I also have an xmos Usb interfaced DAC and have not seen this as I upsample to dsd for all content but I’m considering to move this dac to another room where I play more often and can see what’s happening. It sure what version of the Xmos firmware I’m on.
Not sure. We probably won’t actually be able to know because we don’t have visibility into how XMOS packages their stuff or what modifications are being made to that on a product-by-product basis by DAC vendors.
Every indication here is that the bug is on the DAC side–that is fairly easy to see from the failure mode. The DAC plays invalid sounds, ends up hung, and the entire relationship between the DAC and OS is broken from that point until the DAC is power cycled.
It’s impossible for a piece of software like Roon to cause behavior like this on its own without an underlying bug in the device, kernel, or OS. In our QA experiments, the bad state survives restarting everything but the DAC, which almost 100% isolates the problem to the DAC and almost 100% exonerates Linux/Driver/Roon.
I made an assumption that it was a problem with newer firmware because this issue has not taken shape into a clear pattern until fairly recently, and the products that we have reproduced with are more recent, so the explanation made sense. It’s not something we are 100% sure of, just a theory. We will probably never be totally sure.
We’ve also noticed that the appearance of this bug is wildly inconsistent from system to system. Some systems can accomplish hundreds of format transitions without trouble, and others fail within a few transitions.
Maybe it’s a timing bug–this is a common class of mis-implementation on USB devices that is consistent with all of the above. Some DACs assume that software->driver will exercise state transitions at a slow pace, and run into race conditions/failures when ending a stream + starting a new one in rapid succession (which is the best thing for user experience, and an area that we have put work into optimizing).
If that’s the case, the workaround is straightforward, but distasteful–artificially waste some time at these transition points so that the DAC isn’t overwhelmed. Yuck. But it wouldn’t be the first time we have found a bug like this in a USB DAC. Then there’s a question of whether everyone gets slowed down, or if we can somehow detect devices with this bug. None of this is very pretty…
Thanks for replying Brian, so even though I could not repeat the behaviour via MPD it’s not Roon specifc.? This is good then but just wondering how I could not make it happen in MPD playing the same content in the same order that made Roon crash the DAC everytime? I noticed the buffer size in Roon of the Alaa stream is a lot smaller in Roon compared to MPD could this be a factor?
So I think we can now say more definitively that this issue is in the XMOS firmware on the DACs and not a problem with Linux or Roon/RAAT. We will be reaching out to manufacturers shortly and sharing these details.
@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.