Answer is likely reported in HQPlayer’s log, so please enable it from settings, restart HQPlayer and reproduce the problem. And if you can then email me the log, or you can check it yourself, error lines are prefixed with ‘!’ character.
Newest HQPlayer Desktop versions should also leave the last error visible in the status bar if something goes wrong.
For a RME ADI-2 DAC over USB, I assume 32 bits (or default) is the best? Or is there anything to gain by lowering it to 24 or lower?
Igot the impression that 20 is the best fit, however that may have been in reference to R2R DACS…but could be wrong.
Im now on 20 bits and sounds great
Yes, it can utilize 32-bit data, if you’d want to output PCM in first place at all. And if you do, use 705.6/768k rate. You can pair it with the LNS15 shaper if you like.
But I use my ADI-2 Pro’s in DSD Direct mode at DSD256 for better performance.
If you want to match output levels of PCM and DSD for comparison, set it’s volume control to -3.5 dB (this applies at least to the earlier ADI-2 version I have).
20 bit is good starting point for R2R DACs. If you use noise shaped dithers with it, no harm on other types of DACs either. And no practical harm with TPDF dither either.
But if the DAC is delta-sigma type and you are sending it PCM, it will perform it’s own DSP. Then it is best to send it maximum digital resolution it can understand at highest rate it can accept. Possibly aided with noise shaped dither like LNS15 (for rates >= 352.8k).
It would be fun to try that, but I use the volume on my RME. Would I lose much SQ by using HQPlayer volume, or should I try to get a decent (but not to terrible expensive) passive preamp/volume?
Passive volume controls can be very tricky because they mess up impedance between pre- and power. Certainly you don’t lose sound quality by using HQPlayer’s volume, instead of the digital volume control in AKM DAC chip as in the ADI-2 case, vice versa. But software volume especially on desktop computers have some dangers because of many applications and the systems are complex. With dedicated HQPlayer Embedded computer it is less risky because there shouldn’t be any other potential applications playing sounds, etc.
So other alternative is go with a good quality pre-amp that has buffer stages (impedance converters).
Ill give it a try, I play through an NAA on a microRendu so computer sound is not a factor. Then I’ll set max volume in HQPlayer to as high volume I ever use. To bad the volume is lagging a little, due to NAA/mR and buffers I would guess.
I don’t think RME uses the AKM dac chips for volume though, seem to recall reading about 48 bits volume handling as part of their DSP. On the other hand, I use both RME and HQPlayer volume today (fixed -dB in HQPlayer to avoid clipping), so it should actually be an improvement using only HQPlayer.
I am sorry, but I just can’t see why you would ever want to throw away bit depth data. It makes no sense.
Being the developer, I would like to think Jussi knows what he is talking about. I admit that most of this stuff goes over my head, so I’m relying on the experts (not knowledge know-all’s that frequent these pages…you know the ones lol) for direction
In the case of R2R DACs, its not about throwing away bits, its about where to compensate for lack of number of effective bits, either in HQPlayer or in the DAC. And typically, due to more advanced software and faster hardware, HQPlayer will do that better than the DAC.
Because the R2R ladder is not linear to the last bit, the error is larger than contribution of the 24th bit. So we utilize the ladder’s linear region and use high rate with noise shaping designed for this purpose to linearize it beyond 24-bit.
Here’s example of Spring 2 playing 1 kHz tone at -120 dBFS with 24-bit TPDF dithered input data (1.4112 MHz sampling rate):
Here’s the same, but 20-bit 5th order noise shaped data:
You can see that noise floor is the same, but distortion caused by the ladder non-linearity is gone.
So, we didn’t throw anything away, but we gained a lot. All the information is still there, but encoded in a more clever way that makes the DAC perform better.
At these sample rates we can even drop resolution to 16-bit with 9th order noise shaper and retain the same result:
We can actually keep increasing sampling rate and reducing number of bits and it still looks the same… 
Isn’t that the definition of DSD?
Well, SDM in a way. Of course this is oversimplification, but true in high level terms.
Yes, of course, agree on both. The part I find most interesting about all of this is that there is no one “right” answer; instead it is a series of compromises or tradeoffs and what I love about HQ Player is that my choice of compromises can be different than yours and mine can also be different on Mondays than they are on Sundays… 
Hold on. You are still throwing away some musical data. I don’t think we hear any of that distortion at -140db.
I’m not throwing away any musical data, but to understand that you need to understand how noise shaping works. That is basis of all modern D/A converters.
In fact the noise-shaped 20-bit output has more dynamic range and information in audio band than TPDF dithered 24-bit data.
At higher levels the distortions are also higher, but at low levels their percentage of the the signal are largest. The difference here is 10% distortion at -120 dB vs something much much lower.
Key here is to improve low level linearity, very important for things like classical music.
So I’m now using 20 bit with LNS15. If by going by your chart would NS5 be a better combo than LNS15?
If 20bit/NS5 and 16bit/NS9 are great combos then wouldn’t it then be 12bit/LNS15 be a combo rather than 20bit/LNS15.?
No, LNS15 is better for higher output rates. I just didn’t have it yet when I made those measurements.
20-bit is enough in above case, there is no benefit going below. Reason for 16-bit though is that it is maximum that you can use on macOS at 32x rates. And that way you can get 32x output rates working on macOS without quality loss.
If you are not throwing away musical data, why are files released with 24 bit data? Why not 16 or 12 or 8?
And PCM is not DSD otherwise we could go down to a single bit…
