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.
1 Like
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.
2 Likes
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.
15 Likes
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.
To Roon support?
I would point them (and any manufacturer) specifically to this one post, which also has the link to the xcore thread:
DAC issues with XMOS usb chipset and Roon on Linux
I’ve sent that link to a couple DAC makers, for their info.
Yes
I did as I am the one who created it
Hehe that link I shared is to one specific post. Brian’s one post with the link to the xcore thread.
From personal experience, a DAC manufacturer is unlikely to read this entire thread, top to bottom. So I had to spoon feed them the real crux of the issue, which is the link I shared above to post #15.
I shared it as well
I’ve read this post - https://www.xcore.com/viewtopic.php?t=6417
Just a few dumb questions. Are these the guys that control the XMOS firmware code? Do they then distribute it to the vendors (e.g. Singxer) to then update their firmware to give to customers?
I’m just wondering what the mechanism is to get this fix out in the wild. There hasn’t been any follow up on the thread above since early 2018. Does anyone have insight into this?
Based on the technical information already disclosed, manufacturers have sufficient information to fix that in their own XMOS firmware (if they want to), and release it to customers in their own ways, using their own upgrade methods.
I am curious how many DACs are designed to be able to upgrade component’s firmware like XMOS chip?
Well the Sinxger SU1 allows you to do it. That’s my immediate area of interest as I own one. As to what other manufacturers will do with embedded XMOS solutions, it will be interesting to see what happens in the future.
I’m afraid some will just ignore it and tell you they don’t support Linux. Especially if Roon comes up with a workaround, then those manufacturers may (incorrectly) claim that Roon fixed its own problem, so they don’t have any work do - as reflected in an incorrect view several posts above.
2 Likes
That’s exactly what recently came out the mouth of a hifi- co’s CEO. When I told him it’s not a Linux issue he immediately went on the defensive. Pointed him to the link and he’s been silent ever since. Guaranteed they won’t fix it. I’ll never purchase another of their products again.
Whilst they claimed (and probably believed at the time) it was USB2.0 compliant, it clearly isn’t and the end user sits with the problem.
Yes, you want to buy products from companies who are passionate about quality and want to create and support great products. Me too companies who are only in it for the money just waste space and muddy the waters. Don’t buy it they are not interested.
But you just bought Meridian kit? 