Benchmark DAC3. I’ve done my best with the settings to ensue bit-perfect output. No sound with DoP.–rather, I hear light static and very faint music. Benchmark says DAC3 does not appear to be getting bit-perfect output. Sounds similar to an issue reported late '16 for regular Roon. Solution then was a Roon software update.
My setup: ROCK --> Benchmark DAC3 HGC. Volume Control fixed. Playback settings here:
Here’s my signal path:
Not a lot of interest in my problem it seems–odd. I can now report that it’s definitely a ROCK bug. Works fine with identical settings in Roon on a Mac Mini, always fails on ROCK.
You’re welcome.
ROCK or Roon on Linux?
Not sure I understand your question. I described my setup, and wrote above that it works in Roon on a Mac Mini but not in ROCK/Roon. That makes it ROCK, right?
You are reporting it’s a bug in ROCK with confidence (using the word “definitely”), but that’s not clear to me yet.
It could be ROCK, but it could also be Roon on Linux.
I’m asking if you’ve tested this DoP + Benchmark DAC3 + Linux combination on a non-ROCK Linux install.
Roon on Linux is a different product to ROCK, so I’m just trying to gather some information about this unique situation (I don’t have the Benchmark DAC3).
I experienced this problem in ROCK. It works properly in Roon on a Mac Mini. I have no detailed knowledge of the product, but to me that indicates clearly that it’s a bug in ROCK. Whether it also occurs in Roon for Linux, I can’t say.
JFYI, ROCK does not run a special version of Roon – it’s the stock RoonServer on the custom operating system.
If, theoretically, it worked on ROCK but not on the Mac Mini, your logic would “definitely” determine the problem to lie in MacOS. It’s a possibility for sure, but I’d also say Roon on Mac could be at fault.
What my question was trying to determine is if the operating system configuration (ROCK) is bad or if Roon on ANY Linux is bad. Since you’ve not tested this on a non-ROCK Linux, my question can not be answered 
Unfortunately, this means we may have to wait to get the product in-home. But let’s see… maybe we can do something here.
If you have a Linux box lying around (Ubuntu, Debian, etc…), please do give it a shot… if not, no worries.
It’s possible
I’ve got a dual boot Ubuntu here–but how would I go about this? I can only have one “core” installed at a time, right?
Oh great! That would be hugely useful.
Don’t worry, you can just do the same thing on the ROCK side when you want to go back. Transferring licenses this way is easy and many Roon members do it on a daily basis to move their license between home and their office.
Interesting. That’s very useful to know. I’ll do this later on today.
OK, solved my problems, with help. With Roon running in Linux, I do indeed get music from DSD:
For what it’s worth, doing this in Linux was a bit of a pain. For issues probably related to firewalls, I failed to connect and then crashed several times. Had to kill Roon processes manually before restarting. Did I miss something?
Anyway, I think we can safely conclude that the problem is with ROCK, not Roon for Linux.
I have an idea of what might be happening… can you turn on “force max volume at playback start” in the audio settings for that device?
You’r right. That works. But why? Shouldn’t be that way, right?
No, it shouldn’t.
This means that the DAC exposes a hardware-based volume control over the USB Audio protocol, but that that volume control is not smart enough to adjust DSD properly without ruining the integrity of the bitstream. This usually means that it’s trying to apply a PCM volume adjustment to a DSD signal.
This behavior is far from ideal–since leads to bad user experiences like this one…but it’s not terribly uncommon for manufacturers to make this compromise
This is what I think motivates them: if the device doesn’t expose any volume control, then the device will be inconvenient if used as the “System Output” on a Mac or PC. So manufacturers want to expose some kind of volume control over USB–the problem is many DACs don’t have the DSP horsepower to do a DSD volume adjustment, and can’t or won’t link the USB volume control up with their “front panel” volume which likely works properly for DSD. So sometimes, they feel compelled to add a second software-based volume control inside of the USB interface. This ends up cascading with the “real” volume control on the front panel. In most cases, quality-conscious users would want to leave the first one at 100% to bypass it.
With USB volume controls, it’s up to the computer to remember the volume level–and ROCK does. This suggests that at some point in the past, the volume between the device and Linux (ROCK) was not 100%, and ROCK remembered that state.
Starting fresh on Ubuntu side-stepped the issue, since Ubuntu did not have a remembered volume value for this device, and defaulted to 100%.
In “Fixed Volume” mode, Roon does not touch the device’s volume controls at all. This is important for situations where, for example, the user might want to leave the DAC at a fixed, non-100% volume level appropriate for the next device in the chain, but without exposing that volume in Roon–since it’s not meant to be adjusted casually.
The “force max…” setting you turned on is a workaround for this class of device misbehavior–It is for situations where the device has non-DSD-aware volume control exposed over USB, and also is prone to coming up at less than 100% volume.
I hope this makes sense…please let me know if you have any other questions about this.
Brian, this will take some time for me to study and understand. I’m confused, though, that it makes it sound like the device is misbehaving when it works properly in Roon for Windows, Roon for Mac, and Roon for Linux–that’s three out of four. I bet the answer to this is in your response somewhere, but I’m not seeing it just yet.
@Jim_Austin – the above is the issue you have with ROCK. In other words:
ROCK remembered the last volume and it was not 100%, so it told the device to be that voluime. It remembers this setting between runs/reboots, so you must have had the volume at non-100% before you played the DoP stream.
When the device saw the non-100% volume, it destroyed the stream by doing PCM volume, and not DSD volume.
When you turned on Max Volume stuff in Roon, it told the device “go to 100%”, which made the device stop applying the PCM volume control to the DoP stream. Then everything worked.
Your Ubuntu worked because you never told Ubuntu via ALSA to change the volume to non-100%, so the device was never told to be non-100%. However, ROCK remembered from before the DoP stream.
We are able to reproduce this in all operating systems, by asking the device to go to non-100% and then playing a DoP stream.
One might ask why Roon doesn’t always force Max Volume with DoP, and it is because many manufacturers do the right thing, and apply the volume on the DSD stream.
If you’d like to see this device do the wrong thing on Ubuntu, do this: change the volume to 90% in Roon and play the DoP stream.
It is also possible to reproduce on MacOS. You have to be a bit careful on MacOS because of exclusive mode being something you can turn on/off (Roon on Linux is always exclusive mode). The easiest way to reproduce it on MacOS is to enable exclusive mode, crank the volume to 100%, and then play the DoP stream. Then, as the stream plays, lower the volume in Roon. Roon will tell the device to change to non-100% and you will see the bad behavior.
If the device was behaving well, you’d just hear quieter music.
Danny, on the one hand, I never use software volume controls–I’m preoccupied with maintaining bit-perfect output. On the other hand, I just did that experiment and it went exactly as you said it would–except that when I returned the volume to 100% the sound came back–you didn’t mention that–which makes your argument more convincing.
So, seems like you got it right. Thanks.
I think you understand the situation now, but I was to be clear here: when you were changing the volume in your test, Roon was doing no software volume adjustments – it was telling the device to do the volume adjustment.
Unfortunately, the hardware is clearly doing what we would both characterize as “software volume”, because it’s doing it to the digital PCM stream before it decodes it into analog (thus your DoP falls apart).
Ideally, this device would have changed the analog signal – thus doing the best quality volume control and not having any such bugs like these… but you see this “bad” behavior a lot in the products out there.
Thanks Danny. FWIW–and I’m not an owner, so there’s no ego in this–it sounds superb, measures exceedingly well, and isn’t too expensive. And now I know how to make it work with DSD.
I have seen this with other DAC’s too. Denafrips Ares I recall had this issue. As it doesn’t have a volume control on the DAC itself means I was unable to use without a preamp for DSD playback.
Unfortunately not all DAC’s are equal when it comes to such capability
Someone here was maintaining a database look up of roon friendly DAC’s ad this might be a good place to indicate caveats that might apply.
Personally I thought Benchmark would be better than this based on their high standards. Maybe the roon boys can pass the message down 
