So far in my case, this worked better for DSD1024. I was surprised it could work, but for higher rates 192khz will cause droppings. I’m sticking to DSD 512 with more demanding filters and modulators also great
Many thanks @Stefano_Antonelli & @Deano
Hi all
- Dear @jussi_laako , tell me, do I understand correctly that if a NOS DAC is used, then HQPE works as a DIGITAL FILTER?
If this is so, then theoretically how much better/worse is HQPE than DF implemented on chips, such as SM5847, DF1700, etc.
Could it be that the DF chip is located directly in front of the DAC chips, and the filtered signal using HQPE goes through the wires to the Pure type enpoint, or via USB.
Is it possible to say that HQPE can act as a DF no worse than hardware ones? Or is it different and you still need to install the hardware DF in front of the DAC… - In HQPE there is a “suspend” button, as I understand it, the device goes into hibernation. What command will send you to sleep is clear, and in what ways can you get it out of sleep?
Yes… And if the DAC is delta-sigma type (DSD), also as the delta-sigma modulator. So essentially HQPlayer is replacement for the cheap hardware DSP.
Quite a bit better, and without limitations of those. Those chips OTOH were better than what you commonly these days find inside DAC chips.
Yes, of course. Point of HQPlayer is to do things better than the resource constrained hardware can. Since you have much more processing power and memory available.
Wakeup is typically through a hardware interrupt. IOW, hardware generates event to wake up from sleep.
1 Like
Jussi, Delta Sigma is not taken into account)
Very interesting are the good old R2Rs such as AD1862, PCM63, PCM58.
If you do upsampling using HQPE directly to these DACs, will it be no worse in terms of filtering than the best old hardware DFs?
And the most important question is whether there can be degradation due to the fact that the filtered signal using HQPE passes through several media (network, enpoint in the form of BBB (Pure NAA), USB Amanero or Xing U30) and only after that the signal enters the R2R DAC microcircuit .
When, as in the classic Transport-DF - R2R scheme, the filtered signal immediately from DF goes to the R2R microcircuits.
For example, there is a difference in the sound of Amanero and Xing U30, it seems like both are USB transports, but one sounds better than the other.
Actually, it’s interesting what happens to the filtered HQPE signal along the entire path.
The main question is, for R2R, is it possible to completely abandon hardware DFs… If so, and theoretically it definitely won’t be worse, then that’s great.
What settings must be set to work as DF with R2R chips?
As I understand it, this checkbox is absolutely necessary?
Yes, it is much better than those old hardware chips… And you have plenty of filter options as well.
Just remember to set output bits correctly, and possibly utilize noise-shaped dither. This allows to correct inherent linearity problems of R2R implementations. (something those old DF chips are not capable of doing)
No, it is digital data, it doesn’t get degraded on the way, just like our text here doesn’t degrade even though it is passed through internet…
This has more to do with clock quality of these interfaces. But your DF chip doesn’t have clock of it’s own, that is separate. Those DF chips operate synchronously with the system clock.
Filter choice, dither choice and number of output bits. For best performance you should measure the DAC output low level linearity and adjust “DAC Bits” in HQPlayer to the linear region.
No, certainly not. Please see the manual regarding that setting. It is the cleanup option for bad fake-hires content.
1 Like
Here is example how low level linearity can be improved on Holo Spring 3 R2R ladder.
705.6k 24-bit TPDF dithered input, 1 kHz -120 dB:
Here we have chosen 20-bit output with LNS15 noise-shaped dither instead, you can see all the non-linearity distortion is gone:
4 Likes
By the way, in case anyone doesn’t know, this little guy pulls heavy DSD512 modulators without any problems. And all this happiness for just $600…
AMD Ryzen™ 9 7940HS
5 Likes
Out of curiosity, can it do ASDM7EC-light @ DSD1024??
Noisy fan ? Of course not a problem if outside listening room
@jussi_laako Would this be significantly better than a Mac Mini M1 for the use case illustrated below (screenshot from my other HQP setup, Desktop 5 on a Mini M1), allowing higher than DSD256?
Maybe, someone would need to try it out and report… My MBP with M1Max happily does DSD512 with ASDM7EC-light. Has someone tried with recent Pro if the same runs on Mac Mini? My Mac Mini is still the initial M1 version…
@jussi_laako
I just saw in your latest update for the v5.5.0 that the NAA protocol v5 has been released, could you accordingly tell which version(s) of NAA is(are) supporting this new protocol and what are the added functionalities?
All v5.x ones…
And any plan to have it on the standalone version of the NAA ?
Yes, certainly, now all out. Just had to release one thing at a time.
Great thank you…
Unfortunately, I don’t have this device, but a friend from another forum. I think moving it to another room is not a problem if you want complete silence. Fortunately, now everything works through the network and long wires are not a problem.
The trick here is the price, because the system turns out cheaper than just an Intel processor capable of handling heavy modulators in DSD512
Dear @jussi_laako Jussi, tell me, are there currently ways to combine several USB DACs into one multi-channel one so that HQPE can see this device and output it to a multi-band system?
Unfortunately, there are still no multi-channel DACs with good sound on the market, and based on R2R it’s generally a problem, either make homemade ones or look for something rare and expensive like a YAMAHA DA8X or something like that… And also if you make it all work outside of your home , and in a car, the problem is even more difficult, although it can be solved…
As I understand it, nothing can be done at all through HQPE based on HQP OS?
If this is possible, would you have to use something like JACK(Pipewire)?
It’s just that there are a lot of even portable USB DACs on sale with pretty good sound. And if it would be possible to combine several of them into a multi-channel DAC, it would be great…
I understand that there may be a run-up across the generators, but I think it’s unlikely to be critical or noticeable until the next track switch.
Or, as an option, implement Andpoint like BBB, but which will have something like a jack and an NAA receiver. Several USB DACs will be connected to this andpoint, and the NAA will receive a signal to it from HQPE over the network.
OS drivers can do this in some cases, like macOS and Linux, and some ASIO drivers on Windows. But it won’t work properly unless you can synchronize clocks of these DACs using for example Word Clock cable, which exists for this purpose in pro-audio scope. Some RME devices can also do this through S/PDIF connection. It also requires that each of these USB DACs represent different device name to the OS. So far I’ve only seen RME devices doing this. So if you want to try such setup, RME ADI-2 is your best bet.
If you need only max 192k rate, you have number of options for multichannel AES interfaces that have number of AES or S/PDIF outputs. Like at the moment I have RME Digiface USB connected to my Mac Mini running latest macOS and RME drivers. It has four optical S/PDIF outputs and thus can do 8 channels. This won’t work on Linux though. On Linux there’s for example RME HDSPe AES that could work, with 8 AES outputs.
HQPlayer OS contains usual ALSA drivers, so those ALSA things are available there as well.
https://www.alsa-project.org/wiki/Asoundrc#Virtual_multi_channel_devices
These are usually not designed for such cases, so they all present identical device identifiers to the OS.
1 Like
I think there shouldn’t be any problems with this. I once tried combining several different devices into one in Roon(for windows) using multi-room, and it worked as one. Moreover, one was a PCIex sound card, the second was a DSC DAC, I did not notice any desynchronization in operation. I think with such precision of modern generators, desynchronization can and will happen after several hours of continuous playback.
It turns out the main problem is the same device names in Linux