The DAC uses the VIA VT1731 USB controller, using linux we can see it advertises the rates of 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, and 705600 across all three altsettings. Noting the 705600 rate is not advertised in the specs of the DAC in the Parasound Halo Manual, this will be important later.
Importantly there is no direct DSD mode, all 3 alt settings are PCM only.
Parasound provide Windows 64bit drivers which are driven by the underlying Windows Kernel Streaming(KS). They also provide an ASIO driver which also utilises KS, this driver is 32bit and no longer works with windows 10/11.
Testing a DSD256 :
Windows 8.1 → ASIO 32 bit (KS) driver-> jriver(older 32 bit version) : Successfully plays, jriver shows the format as DSD256 being played direct
Windows 11 → 64bit Windows KS driver → jriver(latest version) : Successfully plays, jriver shows DoP(DSD256)
I don’t know what you tested there, but USB UAC is good for up to 96 kHz only. The more modern USB UAC 2.0, that most all current USB Audio devices support, is good for up to 384 kHz only. USB UAC 3.0 supports more but is still a rare find. Any sampling frequency not covered by the standards (USB UAC) requires a device specific driver.
What makes you say it tops at 384khz? My understanding is Uac 2.0 does not have a limit per say and is capped by the physical limit of the usb port, which exceeds 768khz.
Reality. the UAC specification is for the “driver-less” support where you connect your device and do not need to install a driver to use it. I don’t know of an UAC 2.0 implementation that supports more than 384 kHz. Neither Microsoft’s nor Apple’s stack does. Android also doesn’t to my knowledge. I also never saw evidence that Linux supports more.
Which brings us back to: You need a device specific driver if you want more because the driver-less support from UAC 2.0 ends with 384 kHz (in practice). If you have one, you can do more.
Which most likely just means that your kernel is patched with driver quirks (USB ID of compatible devices got added to a quirks file to allow for higher sample rates) that include your DAC, which makes it a device specific driver (extension). Driver-less support (without patching in device specific USB IDs) still ends at 384 kHz many DACs proof that under Linux. There is a reason why Linux based streamer manufacturers curate their own patched kernels. Roon Labs made it clear in the past that they are not interested in curating their own patched (for maximum USB DAC comparability) Linux kernel, constantly updating and distributing new kernels with support for new DACs, for their Roon OS. They see these device’s primary job not as streamer but as stable and low-effort-maintenance Roon Server (turn-key) appliance.
BTW: What exactly is it you’re asking for?
What works with Roon, what not? Can’t you play in the bounds of UAC 2.0 (384 kHz PCM, DSD128 DoP)? Can you not play DSD256 DoP on the Linux machine with drivers?
So as not to be confusing, DSD Direct playback lately has come to mean that the DSD signal that arrives at the DAC is actually processed into audio from the original 1 bit DSD stream without any extra conversions. The Halo uses an ESS chip which does NOT play DSD directly (none of the ESS chips do actually), it will convert the DSD stream into a multi-bit format and then process that to audio. There are DACs which do play DSD direct.
You could setup an intermediate endpoint that does connect correctly to your DAC via USB and run RoonBridge on it. Which is what Blackjack was suggesting. RoonServer > ethernet> Intermediate Endpoint > USB > Halo.
The endpoint could be one of the PCs you used in testing.
I don’t have quirks added to my Linux build, I explored that option but the DAC doesn’t output DSD. As @Rugby noted the ESS chip advertises its capability as only outputting PCM when I check in Linux.
My initial issue was getting DSD256 either direct or DoP working with this DAC and Roon in Windows. In testing Roon only plays DSD256 files if PCM conversion is enabled. jriver however successfully plays DoP using KS Windows drivers. I’m assuming Roon would need to enable KS drivers?
I’m pretty sure your suggested intermediary method will work, I’ll give it a try later today. It just means more stuff in the chain, which is annoying.
I’ll add that the Parasound manual states the followings specs:
Supported DAC Sampling Rates
USB: up to 384 kHz / 32-bit PCM
DSD Native: DSD 64, DSD 128, DSD 256
DSD over PCM (DoP) at 384 kHz
Coax/Opt: up to 192 kHz / 24-bit PCM
However based on my testing, I don’t believe the DAC supports true native DSD(as Rugby also advised) and is only ever achieving “native DSD” using DoP. My theory is that the ASIO driver receives a hand off from jriver as native DSD, which is why it shows as DSD direct playing, but the driver packages it to DoP before sending it to the DAC using the underlying KS drivers.
This is why when using the non ASIO KS drivers on later versions of Windows, jriver shows DoP(256) engaged which would require the 705600 rate to work. The callout being that this exceeds the stated max rate in the specs for DoP from Parasound but as stated the DAC itself does advertise that rate as being available and Linux show it outputting at this rate. This would be the only way a DAC that doesn’t support DSD direct could play DoP(256).
The previous thread had a good amount of history and context on this issue, I wanted to add my findings to see if it would yield a solution in Roon
What “Roon” are you talking about? Roon (the player software) doesn’t provide USB DAC drivers or deals with the devices directly, this is part of the OS Roon runs on and its drivers. So nothing will change in this regard.
Roon OS (the OS for ROCK and Nucleus devices) comes with a (vanilla) kernel without additional drivers added. That doesn’t mean all USB DACs are limited to 384 kHz though as some drivers got added to the kernel code base over time. So a DAC may or may not be good for higher sampling frequencies - Roon Labs doesn’t make promises here, the situation simply is “as is” with a users DAC.