HQ Player

[bogi]

@satshanti

Direct DSD is recommended with HQPlayer, but also many other aspects of DAC implementation affect sound. I think no general answer exist to your questions. It is always about concrete models and also about personal preferences and rest of the listening chain.

An used Topping D70s (2x AK4497, direct DSD up to DSD512) could be an option within your price range - it has nice reviews and measurements.

 

AFAIK Miska tested Topping D30 pro with 4x CS43198, which provides direct DSD too.

 

I am using much cheaper ESS chip based Topping E50 without any issues and I like the sound with HQPlayer when going to DSD512 or DSD256. E50 advantage is that it supports 48kHz based DSD rates up to DSD256.

 

There are so many models of SMSL, Topping, Aune, Matrix, Loxjie, Soncoz etc. within your price range, that it is hard to suggest something I have no direct experience with. Generally, AKM up to AK4499EX, TI (Burr-Brown) and ROHM always provide direct DSD if they support DSD input. The newest AK4499EX can be implemented in different ways. I don't know about a DAC with AK4499EX within your price range where direct DSD was confirmed (Topping E70 velvet is very questionable in this regard).

[Miska]

17 minutes ago, bogi said:

The newest AK4499EX can be implemented in different ways. I don't know about a DAC with AK4499EX within your price range where direct DSD was confirmed (Topping E70 velvet is very questionable in this regard).

 

I have SMSL DL300, it has direct DSD mode, but it doesn't work correctly at the moment. I have asked SMSL to update their firmware regarding this feature and will certainly report once that's the case. At least they are looking into it. I believe it is currently one of the least expensive AK4191+AK4499EX combos. Since all the SMSL DACs with this chipset seem to share same control interface, this bug likely applies to all their DACs using this chipset.

 

It didn't originally work on Gustard A26 either, but they fixed it with a controller firmware update (one needs to ask their support for the updated version if necessary). They say that current production uses the updated firmware.

 

Due to way AK4499EX works, it can be direct only at DSD128 or DSD256 rates.

 

[Zauurx]

4 hours ago, Miska said:

 

You can work around this by using networkaudiod on the same machine, either for input or output side. Then you have two processes each accessing only one ASIO driver.

 

 

Ingenious !

Something like this : Asio1 > HQPlayer > NAA > Asio2

And in the file (under windows), networkaudio_name.bat, I put : "NETWORKAUDIOD_BACKEND=ASIO2".

I can do the same in input but i don't understand how ? With the same setting "NETWORKAUDIOD_BACKEND=ASIO1" ?

[Miska]

2 hours ago, Zauurx said:

Something like this : Asio1 > HQPlayer > NAA > Asio2

And in the file (under windows), networkaudio_name.bat, I put : "NETWORKAUDIOD_BACKEND=ASIO2".

I can do the same in input but i don't understand how ? With the same setting "NETWORKAUDIOD_BACKEND=ASIO1" ?

 

Use NAA only at either side, at the moment you cannot have more than one NAA instance running simultaneously on the same machine.

 

[Jud]

11 hours ago, satshanti said:

Would that be a reason to avoid ESS chips?

 

They won't have a direct DSD option, so if that is what you are looking for, yes.

[dericchan1]

23 hours ago, satshanti said:

The Zen DAC Signature v2 for instance, which has direct DSD. I'm also eyeing an Aune X8 XVIII Magic DAC with Sparkos that has 7 different filters, so probably no direct DSD. Also looking at various SMSL options, some of which (the ones with AKM chip) have direct DSD, as far as I understand. Would that be a reason to avoid ESS chips?

I had the ifi neo idsd for about a couple of years, was so happy with it that I upgraded to the pro idsd. I also have pcm based dacs - chord mojo 2 and a Cayin RU6. The pro idsd is still my favorite dac out of the three dacs.

 

The ifi signature is probably a good choice if you are looking for native dsd up to 256. I upgraded my pc so I could try dsd512 with the pro idsd but ended up sticking with dsd256, it just sounds a touch cleaner/darker/quieter with my main system having a tube preamp and the tube buffer stage of the dac.

perhaps another dac you can look into is the Cayin RU7 that is a discrete 1 bit Dsd r2r dac upto dsd256 that should work extremely well with hqplayer.

 

https://en.cayin.cn/features/7/124/603.html

 

[satshanti]

2 hours ago, dericchan1 said:

Perhaps another DAC you can look into is the Cayin RU7 that is a discrete 1-bit DSD R2R DAC up to dsd256 that should work extremely well with HQPlayer.

 

That is a great recommendation! I was so impressed and fascinated by the many reviews online that I couldn't resist to just order one on AliExpress just now. They had a sale on and I paid £210 with free shipping. I could always pass it on if I don't like it, but it looks very promising indeed.  

[CJH]

Is there any reason (improvements) to use HQPlayer if you are using DSP active speakers from Genelec, Neumann, KEF, etc...?

CJH

[dericchan1]

3 hours ago, satshanti said:

That is a great recommendation! I was so impressed and fascinated by the many reviews online that I couldn't resist to just order one on AliExpress just now. They had a sale on and I paid £210 with free shipping. I could always pass it on if I don't like it, but it looks very promising indeed.  

Having owned the RU6 and impressed by it, the RU7 should be at least equal if not better.

 

The RU6 and RU7 are one of those dacs that sound like poop without hqplayer but are true gem with hqplayer!!! The differences with and without hqplayer are absolutely night and day!!

[satshanti]

1 hour ago, dericchan1 said:

Having owned the RU6 and impressed by it, the RU7 should be at least equal if not better.

I've watched and read a ton of reviews and comparisons between the two, and the consensus seems to be that the RU7 is better across the board, with the RU6 being described as "a tad more smooth or analog". 

[dericchan1]

16 minutes ago, satshanti said:

I've watched and read a ton of reviews and comparisons between the two, and the consensus seems to be that the RU7 is better across the board, with the RU6 being described as "a tad more smooth or analog". 

I have had tried my friend’s RU7 and compared with my RU6, especially I had tried setting hqplayer pcm bitdepth to 13 or 14 bit, it’s almost like listening to very clean vinyl without clicks and pops
 

the RU6 is indeed a tad smoother and more analog sounding, both are excellent and very much on par when you use them with hqplayer.

[satshanti]

12 minutes ago, dericchan1 said:

Especially I had tried setting HQPlayer PCM bitdepth to 13 or 14 bit, it’s almost like listening to very clean vinyl without clicks and pops

I'll have to look into that. I remember reading about reducing bitdepth for R2R DACs in this thread a while back but didn't pay much attention. 

[Miska]

4 hours ago, CJH said:

Is there any reason (improvements) to use HQPlayer if you are using DSP active speakers from Genelec, Neumann, KEF, etc...?

 

Yes there is. These are almost invariably performing DSP at fixed sampling rate and converting all other inputs to the internal processing rate. There's benefit to move that conversion to HQPlayer algorithms instead of the built-in ASRC or similar.

 

IIRC, Genelec is using 96 kHz internally.

 

[semente]

I'm using an integrated amplifier and have a bit too much gain.

 

Is it better to attenuate with HQPlayer (set the Max Volume to -12dB) or to set the RME ouput Reference Level to -5dB?

[Miska]

3 hours ago, semente said:

Is it better to attenuate with HQPlayer (set the Max Volume to -12dB) or to set the RME ouput Reference Level to -5dB?

 

Either way works fine. Is the RME reference level adjustment enough / suitable amount? If so, that is one good way.

 

In many cases, dropping the digital output level by few dB reduces DAC's output distortion while adjusting analog level necessarily doesn't since the distortion originates from the D/A conversion and analog I/V and filter stages. Usually analog gain adjustment happens afterwards.

 

In my case, I have ADI-2 reference level set to the middle value, but I don't remember anymore which numeric value it was. When the DAC is running is DSD Direct mode, it also drops the output level by couple of dB compared PCM mode. But overall, given ADI-2's specific implementation, I would say there is not much difference which way you take.

 

[semente]

@Miska does external upsampling/upconversion produce higher jitter levels than on-board processing?

I am assuming, mayble erroneously, that on-board upsampling reduces jitter.

[Miska]

4 hours ago, semente said:

@Miska does external upsampling/upconversion produce higher jitter levels than on-board processing?

 

No, jitter only happens at the point where conversion from digital to analog happens. As long as we are dealing with data in digital domain, jitter doesn't exist.

 

4 hours ago, semente said:

I am assuming, mayble erroneously, that on-board upsampling reduces jitter.

 

On-board upsampling increases jitter as I have shown through couple of measurements. Not because of the DSP process itself (unless it is ASRC there), but because the processing near the D/A conversion stage generates EMI/RFI that disturbs the actual D/A conversion and thus introduces jitter there. When there is minimal on-board processing, there's minimal amount of EMI/RFI from the digital side.

 

This is also one reason why DAC chip manufacturers cannot put advanced algorithms on the same chip with the sensitive conversion stage. Like AKM recently came up with the AK4191 + AK4499EX chip pair to keep the processing and conversion separate. Which is how things used to be in the past, when the digital filters were housed in a separate chip from the D/A conversion chip. For cost reasons those were moved to a single chip architecture in late 90's.

 

And also one reason why some companies like Chord, dCS and Esoteric have been doing separate upsampler and converter devices. (very expensive and underpowered though, compared to modern computer + software)

 

So certainly best to keep all DSP external and just have the D/A converter do the D/A conversion as well as possible. Holo Audio being one example on that area.

 

[bogi]

1 hour ago, Miska said:

No, jitter only happens at the point where conversion from digital to analog happens. As long as we are dealing with data in digital domain, jitter doesn't exist.

But I see jitter measurements of digital to digital converters. Are they using wrong terminology in your opinion?

I know it is not about upsampling DSP what semente was asking for, I just want to understand.

 

SMSL PO100 pro measurement

 

Topping D10 balanced measurement

 

 

 

[Miska]

42 minutes ago, bogi said:

But I see jitter measurements of digital to digital converters. Are they using wrong terminology in your opinion?

I know it is not about upsampling DSP what semente was asking for, I just want to understand.

 

SMSL PO100 pro measurement

 

Topping D10 balanced measurement

 

 

 

 

These jitter things happen at the digital-to-analog edge. As long as the data is in digital format, there's no jitter, as there's no clock. For example FLAC, WAV or DSF file doesn't contain any clock. Clock begins to apply only when the data is converted to analog.

 

For example when you use HQPlayer to process from such S/PDIF source and output to asynchronous USB DAC, such jitter doesn't apply. Because the only involved clock will the one built into your DAC. HQPlayer doesn't use the incoming clock for anything else than determining whether it is for example 44.1k or 48k source. No different than reading a WAV/AIFF file.

 

S/PDIF and AES/EBU is source-clocked and the DAC is slaved to the source's clock. Same applies to I2S-LVDS. Due to how S/PDIF and AES/EBU work, the DAC needs to reconstruct it's master clock from the incoming data stream from the S/PDIF. This happens through a PLL which can never be perfect. Holo Audio has a very good PLL that is only slightly worse than it's built-in clocks, but down side is that is has rather long lock time, in order of seconds or so.

 

As shown above, you can measure stability (jitter) of clocks from S/PDIF or AES/EBU source, as well as I2S source. This is useful in terms of determining how much jitter the receiving PLL needs to try to suppress. But it doesn't apply to anything until the clock is actually used for something. And in these cases, the clock that would apply would be the reconstruction made by the PLL. Not the clock directly coming from the source - except if your source is I2S-LVDS and it is not going through PLL. For example with Holo DAC, using I2S input with the PLL disabled will typically have about 10x more jitter than when it is configured to go through the PLL clock regeneration, which is only slightly worse than when using USB through with the built-in oscillators.

 

However, if your source is asynchronous USB or network protocol like NAA, there's no associated clock and thus no jitter to measure. Just as there's no jitter to measure when you are streaming for example from Qobuz cloud servers. There is no more jitter associated than this text or those pictures, or any other random data file you have on the internet. Sure, the ADC used for the original recording may have had jitter in it's clock. Just like DAC clock may have. But that would be baked into the data throughout and is not affected along the way.

 

Overall, you never want to transfer clocks across devices. D/A conversion clock oscillator should be mere millimeters away from the actual conversion stage, to minimize any external EMI/RFI or PCB capacitive connection to any other lines (PSU or such) or signals. Any disturbance of the conversion clock will show up as jitter in the analog output. And such disturbance is not necessarily related to the source at all, it could be some other internal or external source. Such as ground current, thus for example USB isolators address a completely separate path.

 

DSD as conversion format is far less sensitive to jitter than R2R PCM clocks. Because both the clock period time is much shorter and also relative (statistical) contribution of single DSD sample to the output signal is much smaller than contribution of single PCM sample.

 

[LoryWiv]

1 hour ago, Miska said:

DSD as conversion format is far less sensitive to jitter than R2R PCM clocks. Because both the clock period time is much shorter and also relative (statistical) contribution of single DSD sample to the output signal is much smaller than contribution of single PCM sample.

 

Understood (I think). Does it therefore follow that if we use HQP to output SDM and one's DAC does DSD direct with no processing / no conversion to PCM the jitter increase from upsampling is avoided or at least minimized?

[mrba]

How to set up the use of CUDA in HQPlayer OS with HQPlayer Embedded?

[bogi]

HQPlayer OS does not support CUDA, since it contains realtime Linux kernel, where nVidia drivers are not supported.

To use CUDA, you need to install a supported 64-bit OS Linux distribution with low latency kernel.
See https://www.signalyst.com/embedded-install.html? for more information.

 

[bogi]

@mrbasee also
https://audiophilestyle.com/forums/topic/63747-how-to-install-hqplayer-embedded-on-ubuntu/

https://community.roonlabs.com/t/how-to-install-hqplayer-5-0-embedded-on-ubuntu/243231

[mrba]

thanks for the links

[Miska]

2 hours ago, LoryWiv said:

Understood (I think). Does it therefore follow that if we use HQP to output SDM and one's DAC does DSD direct with no processing / no conversion to PCM the jitter increase from upsampling is avoided or at least minimized?

 

There's no jitter increase from upsampling. There's jitter reduction due to upsampling...