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:
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.
Connect your Roon Remote to the Ubuntu Roon Core and login
It’ll complain about how you lack licenses, but you can deauthorize the other Core. Just deauthorize your existing ROCK Core and you will start right up.
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.
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.
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.
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.