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.
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?
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
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.
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.
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.
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 .
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.
By the way, I sent an email to DEQX support team. Hope this will help.
Your analogy is terribly weak. Bottom line, the XMOS chipsets that present problems do not fully meet the USB 2.0 Specification. Hardware manufacturers should do better in procuring standards compliant hardware for incorporation in their products. Instead they say “Linux isn’t a supported operating system”, whereas if the USB chipset actually met the specification there’d be no issue at all.
An analogy is an analogy, and to me this one is not weak. I fully understand the root cause: the problem seems to be the good respect or not of the USB standard by manufacturers. If standards are not respected, manufacturers are to move to respect those. Yes you are right.
But Roon, as a professional software maker, has to take this into account one way or the other. At the present moment and as a customer, the service is not delivered but was with not so prestigious solutions.
A standard is there to be met. Workarounds break more than they fix, it is lazy to do things that way. Highlighting the bug to those who have it is the correct way to rectify it. I am in Telecoms and if we did it the wrong way, A would never speak to B reliably.
It’s not easy or hard…just the truth, when it comes to this specific issue. If we wanted the easy way out, we’d be ignoring this, not explaining this to manufacturers over and over + doing the work to get this fixed properly. That takes much more time and effort than a technical fix.
I’ve actually been in that situation, and I distinctly remember not asking the mechanic to “fix” the car to accept bad gas in the future. I changed out the gas, decided it wasn’t worth trying to get the $50 back from the pumping station, and remembered never to go back there.
Part of why products in this industry (as a whole) have lingering flakey issues like this is because many manufacturers treat their product as immutable after it has shipped and expect software fixes to close the gap. Yes, when you are making an analog amplifier, that is how it works, but today’s DACs typically have multiple updatable software-driven components inside, plus a driver. And all of those are fair-game for long-term maintenance and proactive QA to ensure long-term OS-level compatibility.
It’s not good for consumers in this space if hardware to becomes abandonware as soon as it is sold. Doing hack+slash workarounds for DAC bugs encourages this. It’s terrible that so many of us are walking around with a mental model about what works or doesn’t work with what. We deserve better interoperability than that.
Patching around this in our world (we could–just in Roon, though. This bug can be avoided 99% of the time by pausing for an extra tenth of a second when switching formats). would, in a selfish way, be good for us–since we would be the repository of the workarounds and quick-fixes and other players would have to hop that bar to catch up, but it’s not good for the industry or its customers when devices are so quirky.
Imagine if Apple made similar changes in their kernel and exposed this bug. It would be much better for you if it was already fixed in the hardware. Apple certainly would not be listening to you or coordinating remediation efforts like we are.
Generally the response we have gotten from manufacturers is positive and cooperative. I think they will get this fixed. Work takes time…but in my view, some short term pain is justified if it nudges everyone in the right direction.
We are providing service, just not in the way you would prefer. Actually, we are doing something much more expensive and painful than software patching.
The service we are providing is talking to manufacturers, analyzing/finding the technical details, explaining the issue clearly to everyone in the open, avoiding tons of repeat effort across manufacturers to figure this out one by one, and doing what we can to get this fixed for you long-term no matter what software you choose to use.
This seems better than putting some bubblegum+tape on it today, forgetting it ever happened and waiting for the next issue like this to come up…maybe you disagree, but that is my view.
Brian, I appreciate your argument and your virtuous position here – the abandon-ware problem with hardware manufacturers is a real one.
But I’m not buying the argument, because you’re not really on the horns of a dilemma – you could alleviate the pain to Roon users by adding that 1/10 second pause you mention, while still working with manufacturers to fix the problem more fundamentally. By not doing that, you seem to be attempting to use your customers as a tool of some sort, a lever or bludgeon on the manufacturers, to accomplish your agenda.
This issue is also escalating rapidly with more and more users having this problem. Something needs to be done before customers start loosing faith. wyred4sound just put in a thread to support about their customers having issues which points to the same issue. I have pointed them to here.