Hello, I’m looking at buying a Gustard U16 USB converter. I’m wondering if Roon has had a chance to look at integrating the drivers into the Roon Rock Linux core? I appreciate it is a new device and it uses an ESS chip rather than the much more common XMOS chip. Just wondering if there is a time frame for this!
You need to approach Gustard themselves and get them to provide the information that will enable an appropriately patched Linux kernel to recognise the U16’s capability. Once done ROCK should assimilate the required patches in a future update. Otherwise you are stuck with the normal Linux class 2 capability.
The XMOS would be recognised as a generic USB device too but my understanding is that if you don’t install the specific drivers then you can’t access higher bitrate and sampling rates. If consumers refrained from purchasing units that required specific drivers to access all of their potential then it might be a baron wasteland out there.
Thanks for that response and clarification. I was just wondering out loud whether “standard USB” means - full DSD and high bit rates or whether it means “capped to 96khz, 24 bit” or whatever the current limit for generic USB audio devices is. I’m going to buy the Gustard U16 this week all being well so I guess I’ll find out myself soon enough.
He’s talking about the actual standards documents for transmitting audio over USB.
There are different versions of the USB Audio specifications. The 1.0 version is capped at 24bit/96kHz, yes. It is still used for some low quality applications, but the audiophile world moved on to the 2.0 version of the spec years ago and it’s somewhat rare to run across a product that is pinned to USB Audio 1.0 anymore except at extremely low price points.
USB Audio 2.0 supports much higher data rates, and can be stretched to accomplish Native DSD playback (even though the spec does not directly take into account DSD).
ROCK supports both specifications, and in conjunction with Roon supports PCM sample rates (up to 768kHz), DoP based DSD playback (up to DSD256), and Native DSD modes (up to DSD512). This works on hundreds of USB DACs based on the 2.0 standards.
Native DSD support is sometimes patchy on Linux, depending on which DAC manufacturers have done the work to get their DACs supported in the kernel. We take updates from “upstream” pretty frequently, so we are usually up to date on this stuff, but there is often a delay between when a DAC is released + when Native DSD modes are supported in Linux for that device. Until then, it still works in all other modes of course.
Since this product is based on an unusual USB solution that is relatively new, my best guess is that all PCM rates will work, DoP will work, and Native DSD may or may not work until Linux has had enough time to catch up + incorporate support for Native DSD modes on this chip. But I don’t know that for sure–it’s possible that it is already supported, too.
Also–found this on another forum when researching the chip. Can’t confirm/deny the content, I’d want to see this kind of background before making a purchasing decision.
I am not fussed about DSD in the short term. I was just making sure it was on the Linux / Roon horizon so that they were aware of the new ESS chip. I am not going to give up the Roon Rock even if it means running 96khz to be honest! My Direct Stream Junior upsamples everything to DSD anyway so having a higher bitrate may or may not be an issue.
I’ve read that too. But then you take into consideration that this “soundbar” chip has the ability to handle DSD and high bitrate PCM and you have to wonder, why can’t it work well if implemented properly? It seems pretty disingenuous for ESS to make a statement like that since they are effectively dengrading the efforts of one of their customers. Interesting business plan
It should also be noted that the XMOS U8 core, which my Singxer SU1 uses is pretty old and it could be argued that it has now been superseded by the XMOS 200. It still sounds fine, when well implemented!
The link that I provided is a bit of a read but does shed some light on the efforts that Gustard have gone to in the implementation of the chip.
I’m not sure of the conditions underwhich the test were carried out but assuming they are valid and useful, the point towards a low jitter, low noise device:
Does anyone have an email address or website that I can use to provide feedback directly to Gustard? Their PS Audio I2S implementation isn’t correct. With any PCM signal they accidentally have a pre-emphasis flag being used through the I2S output. This is an issue.