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.
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
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.
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.
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 .
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.
ā Edit
By the way, I sent an email to DEQX support team. Hope this will help.