HQPlayer's Network Audio Adapter

[Miska]

19 minutes ago, Carl Mawer said:

Do you know if  http://www.orangepi.org/orangepipc2/

would work with the naa-356-x64 image that you provide?

 

No, unfortunately it won't... It is ARM architecture while the image is for Intel/AMD.

[Luvdac]

Need help please!

I'm running sonictransporter i5 ( soon to upgrade to an i7 machine) running roon and hqplayer embedded. On the other end of the network an allo usbridge to chord hugo 2.

I cant figure out how to get native dsd to the chord hugo 2. I can only get dop upto 256 dsd. I would like to get 512 rates as the hugo 2 is capable of it. If I uncheck dop in hqplayer settings I get pcm output. What am I missing here?

 

[Miska]

5 hours ago, Luvdac said:

Need help please!

I'm running sonictransporter i5 ( soon to upgrade to an i7 machine) running roon and hqplayer embedded. On the other end of the network an allo usbridge to chord hugo 2.

I cant figure out how to get native dsd to the chord hugo 2. I can only get dop upto 256 dsd. I would like to get 512 rates as the hugo 2 is capable of it. If I uncheck dop in hqplayer settings I get pcm output. What am I missing here?

 

You need to ask Andrew about driver support for the Hugo 2. But I would recommend to stick to 705.6/768k PCM outputs to Chord DACs because they internally convert DSD inputs 705.6k PCM.

 

[Luvdac]

7 hours ago, Miska said:

 

You need to ask Andrew about driver support for the Hugo 2. But I would recommend to stick to 705.6/768k PCM outputs to Chord DACs because they internally convert DSD inputs 705.6k PCM.

 

Thanks!! That bit of info about the chord dac converting everything to pcm is news to me. I thought I bought a native dsd dac. Now it seems it is only dsd capable and not a true dsd dac. I'm not too sure I'm happy with the folks over at chord for this misinformation.

Could you recommend a true dsd dac that would accept dsd512 streams from hqplayer + roon over the usbridge? Something under the 1000$ range would be what I could afford right now.

[Miska]

6 hours ago, Luvdac said:

Could you recommend a true dsd dac that would accept dsd512 streams from hqplayer + roon over the usbridge? Something under the 1000$ range would be what I could afford right now.

 

That budget and requirement makes it quite tight and I don't have info about USBridge. Not sure where the TEAC UD-505 is now, I still haven't got one but it's on my purchase list. Holo Audio Cyan is best at DSD256 but can do DSD512 too. RME ADI-2 can do DSD256 very well when configured for DSD Direct mode, and so does TEAC UD-503 with the same DAC chip.

 

Also some iFi DACs can do DSD512 nicely, after firmware downgrade to a one that supports DSD512.

 

So there are some alternatives, but depends on your preferences which way would be good.

 

[Luvdac]

Many thanks for your input. The ADI-2 was on my list but I went with the chord as I was getting it at a hefty discount. I regret that purchase decision now as I always found the chord to be a bit clinical. I wanted to like it but now I know that it's that pcm I have been hearing. Thanks again!

[AudioXP]

On 4/21/2019 at 11:59 PM, Miska said:

Holo Audio Cyan is best at DSD256 but can do DSD512 too.

 

Hi Miska, two questions wrt Holo Audio. 1) What - if anything according to you - makes Holo Audio Spring better than Cyan? 2) Is DSD1024 a similar improvement over DSD512 as is that latter over DSD256?

[AudioXP]

I have another question - using the naa-355-raspberrypi3-64 image on a pi 3B+ the network interface doesn't get an IP address allocated. I then managed to modify the image - removed the DHCP entry in the wired.network file and replaced it by an "Address=a.b.c.d/24" entry. Now ifconfig shows the interface address I've assigned, but there is still no network connectivity and ping from any other host on the subnet doesn't return a response. Ping from the raspi itself works. The network I'm on is my internal home LAN, so it's working, including DHCP. Something I've overlooked? I feel like I'm not far off 🙂

[Miska]

8 minutes ago, AudioXP said:

I have another question - using the naa-355-raspberrypi3-64 image on a pi 3B+ the network interface doesn't get an IP address allocated. I then managed to modify the image - removed the DHCP entry in the wired.network file and replaced it by an "Address=a.b.c.d/24" entry. Now ifconfig shows the interface address I've assigned, but there is still no network connectivity and ping from any other host on the subnet doesn't return a response. Ping from the raspi itself works. The network I'm on is my internal home LAN, so it's working, including DHCP. Something I've overlooked? I feel like I'm not far off 🙂

 

Sounds like some problem with the ethernet driver. If you leave DHCP on and Wireshark from another machine, can you see the DHCP request messages going out? If you ping out from the RasPi, do you get anything going out or any response?

 

[Miska]

19 minutes ago, AudioXP said:

Hi Miska, two questions wrt Holo Audio. 1) What - if anything according to you - makes Holo Audio Spring better than Cyan? 2) Is DSD1024 a similar improvement over DSD512 as is that latter over DSD256?

 

I just get lower noise and distortion figures from Spring than I get from Cyan DSD. I don't know what is the exact hardware difference and if I should be getting the same or something...

 

Sweet spot IMO for both is DSD256, but it is up to you to decide, it is not black-and-white clear thing.

 

[AudioXP]

Using tcpdump (see below), it look like the Raspi (10.10.10.165) is ARPing for the MAC address of the router (InetRouter.lan) and vice versa. Also the Raspi seems to react to multicast group queries by returning igmp reports. Looks like something is going on on the interface...

 

root@herkules:~# tcpdump | grep 10.10.10.165
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
0:57:00.283618 ARP, Request who-has InetRouter.lan tell 10.10.10.165, length 46
20:57:02.971765 ARP, Request who-has 10.10.10.165 tell InetRouter.lan, length 46
(...)

20:57:27.867678 IP 10.10.10.165 > 224.0.0.199: igmp v2 report 224.0.0.199
20:57:28.123658 IP 10.10.10.165 > 224.0.0.252: igmp v2 report 224.0.0.252
(...)
20:57:32.475693 IP 10.10.10.165 > 239.192.0.199: igmp v2 report 239.192.0.199
 

[AudioXP]

1 hour ago, Miska said:

Sweet spot IMO for both is DSD256, but it is up to you to decide, it is not black-and-white clear thing.

 

Thanks for giving your view. I remember you recommending (in this thread I believe) DSD512 over DSD256 for best SQ, indepent of DAC and filter selected. Now since recent I got an SMSL SU-8, after having used an ifi micro BL. First I used it with debian stetch NAA with networkaudiod. This way I got only DOP DSD256 out of it. With your bootable image native DSD512 worked. With the DOP DSD256, without initially realising it was not the DSD512 I got used to with the micro BL, the "magic" was gone. When I got DSD512 to work on the SMSL, the "magic" was back! A "blind" test without realising 🙂

[Miska]

2 minutes ago, AudioXP said:

Thanks for giving your view. I remember you recommending (in this thread I believe) DSD512 over DSD256 for best SQ, indepent of DAC and filter selected. Now since recent I got a SMSL SU-8, after having used an ifi micro BL. First I used it with debian stetch NAA with networkaudiod. This way i got only DOP DSD256 out of it. With your bootable image native DSD512 worked. With the DOP DSD256, for me the "magic" was gone, without me initially realising it was not DSD512 which I got used to with the micro BL. When I got DSD512 back to work on the SMSL, the "magic" was back! A "blind" test without realising 🙂

 

With iFi, DSD512 is the way to go. It is pretty DAC dependent. And Spring does DSD512 better than Cyan, for reason I don't know...

 

I could put it in a different way; if you ask traditional objectivist, DSD256 on Spring is better. If you measure things the way I do, you may begin to think that DSD512 may be better after all. And then in the end you can listen... Either way, from objective technical perspective you are not going wrong.

 

[Superdad]

Yup, DSD256 on my Spring L3 is mighty sweet.

I also greatly enjoy PCM 352.8 with poly-sinc-short an NS5.  Amazingly dynamic and lifelike. The trick is getting DAC-bits setting dialed in just right (hint, it should be much lower than you would expect).

[Bob Stern]

Alex, what dither bit setting have you found ideal for the various DACs you've seriously experimented with?  You don’t have to identify the DACs if you don’t want to, but I'm interested to know the dither setting for the best and worst DACs.  I'd guess 19-bit would be ideal for most state-of-the-art DACs.

[Superdad]

6 hours ago, Bob Stern said:

 I'd guess 19-bit would be ideal for most state-of-the-art DACs.

 

Well I have not had all that many DACs through there—and certainly no parade of expensive “state of the art” units —but your 19-bit guess is spot on for the Spring and for the custom PCM1704 DAC I own.

 

And I am always curious about what setting others have found best.  Getting DAC-bits setting right in HQP really allows the benefits and differences of the various dither settings to be heard.  I think this is a pretty important part of dialing in HQP for best SQ.

 

[Miska]

4 hours ago, Superdad said:

Well I have not had all that many DACs through there—and certainly no parade of expensive “state of the art” units —but your 19-bit guess is spot on for the Spring and for the custom PCM1704 DAC I own.

 

I'm using 20-bit on my Spring(s) based on my measurements. Works very well, and if you run Spring 2 at 1.4112/1.536 MHz PCM rate you get rid of most of the "PCM problem". At such high rate plus noise shaping, you can even drop down to 16-bit and still have 100 kHz worth of SNR as good as analog side allows.

 

[firedog]

6 hours ago, Superdad said:

 Getting DAC-bits setting right in HQP really allows the benefits and differences of the various dither settings to be heard.  I think this is a pretty important part of dialing in HQP for best SQ.

 

How do you have an idea what this is? Listening tests? Few DACs come with this spec defined. 

[Superdad]

1 hour ago, firedog said:

How do you have an idea what this is? Listening tests?

 

Yep, just listening and bracketing (starting by swinging wide to get a sense of what changes, then back and forth, closer and closer until it becomes apparent).  That's also how I used to tune Advanced iZotope filter settings in A+ before I switched to HQP a few years ago.  That's also how I do speaker positioning down to about 1/8-inch. 

 

P.S. I just looked at my HQP prefs and see that with the Spring I actually have been listening at the same 20-bits Miska recommends, not 19 (that must have been with my other DAC).  Sure sounding great these days, especially with my new 47--position Slageformer for level control (replacing my $12K Hovland preamp); Bass to the basement and nuance galore!

[AudioXP]

On 4/28/2019 at 3:12 AM, Superdad said:

Yup, DSD256 on my Spring L3 is mighty sweet.

 

To the experts and the ones with the experiences 😉 - what can be said about HQPlayer SDM upsampling into R2R ladder DACs ? E.g. using DACs from Holo Audio or Audio-gd. Also how do they compare, among each other and to non-R2R DACs?

[ted_b]

FYI. The DSD side of the Holo is not R2R but instead a filterless DSD multi-element array design like Jussi’s own designs. The PCM side is R2R

[Volodymyr]

I saw discussions of NAA image for running NAA endpoint in RAM mode only.  Quite interesting option.  Does it mean that endpoint PC can be without OS installed and without HDD at all?    This image for RAM - is it compatible with any CPU?

How much RAM volume would be safe enough for running such image for 6 channels of 24/192 stream from main PC ?

[acatala]

Hi @Miska,

 

in the first place, thanks for your adjustments in HQPlayer OS 4.10.x that let Rotel RC-1590 (AKM's AK4495 based) play native DSD. I appreciate it very much.

 

I am currently booting my UP Board from a USB drive but now that the DSD issue is solved, I am going to write the image in the internal eMMC drive. So I wonder if I would better write a simple NAA image instead of a HQPlayer OS image. I am going to use the NAA function (Ethernet to USB bridge only). If NAA would boot faster than HQPlayer OS, which I don't know, I would not get any advantage by booting the latter.

 

If NAA would be the fastest option, we would need a NAA modified image with the adjustments included, right?

 

By the way, I am still using HQPlayer Embedded 4.9 in the NUC and HQPlayer 4.10.0 in the Up Board. I will update both this weekend to 4.10.2, or the version available at that time.

 

[Miska]

6 minutes ago, acatala said:

I am currently booting my UP Board from a USB drive but now that the DSD issue is solved, I am going to write the image in the internal eMMC drive. So I wonder if I would better write a simple NAA image instead of a HQPlayer OS image. I am going to use the NAA function (Ethernet to USB bridge only). If NAA would boot faster than HQPlayer OS, which I don't know, I would not get any advantage by booting the latter.

 

The two images are mainly different in the way they run. NAA image runs from RAM, so it likely doesn't get broken even if you pull the power randomly (HQPlayer image shouldn't either though). But due to that, it boots quite a bit slower than HQPlayer image since it needs to load entire filesystem to the RAM at once.

 

Another difference is that HQPlayer image runs multiple network interfaces in bridged setup, while NAA image doesn't create any bridge and assumes just one ethernet interface being in use. So the NAA image has lower CPU load/traffic for networking functions.

 

You can also disable HQPlayer startup from the image with command "systemctl disable hqplayerd" which will make the HQPlayer image boot even faster.

 

11 minutes ago, acatala said:

If NAA would be the fastest option, we would need a NAA modified image with the adjustments included, right?

 

Yes, I can try to update it some time soon, for example next week. Ping me if it doesn't appear by end of next week...

 

[acatala]

OK, thanks @Miska

 

28 minutes ago, Miska said:

 

NAA image runs from RAM, so it likely doesn't get broken even if you pull the power randomly (HQPlayer image shouldn't either though).

 

That feature interests me. It's nice just pushing the power button to power on/off and forget about shuting down.

 

31 minutes ago, Miska said:

Another difference is that HQPlayer image runs multiple network interfaces in bridged setup.

 

I only use the Ethernet interface, so from this point of view it does not apply to me.

 

33 minutes ago, Miska said:

You can also disable HQPlayer startup from the image with command "systemctl disable hqplayerd" which will make the HQPlayer image boot even faster. 

 

It would be a nice option too, indeed, but I should run the shutdown command or leave the NAA powered on. I can consider this option too.

 

41 minutes ago, Miska said:

I can try to update it some time soon, for example next week

 

Thanks. I am not in a hurry. Currently it works and works well, so no problem at all.