I can actually hear better SQ on songs with 48 rather than 44.1.
It might be a slight difference but it is still there.
For sure I wouldn’t put thousands of dollars on GPU’s and I am not sure that would solve the case.
My computer goes to 100% in less than a second when unchecking auto rate.
Maybe it is the Lampi that can’t do this conversion and not the CPU…
That’s a little different than upsampled to those rate families. At those low sample rates we are talking about DAC filters that might work in frequencies in the extremes of human hearing.
1 Like
Dropping to DSD256 still doesn’t solve the problem for closed-form, because none of the 48k-base DSD rates work correctly with Spring 1 (it will use 44.1k clock and play too slowly).
Spring 2 doesn’t have this limitation.
There are no DACs that can do DSD only at 48k-base, so the inability to run something like poly-sinc-xtr from 44.1k to 48k-base DSD is not so much of a problem. Other way around from 48k to 44.1k-base DSD is not nearly as heavy and can run at least on a GPU. Since being limited to 44.1k-base DSD on DAC side is somewhat common, testing 48k to 44.1k-base DSD is more interesting case.
1 Like
Hi Sean! Can you please tell me how to install HQPlayer on my NUC7i7DNHE with ubuntu server 18.04 and Roon Core ?
Hi @Katun
Maybe start with this great PDF guide and if you have trouble, ask here and I can try to help.
I run HQP Embedded on minimal headless Debian Server (never used Ubuntu).
1 Like
Could not connect to web interface 
:
Network Error
An error occurred while accessing
http://192.168.1.50:8088/config.
This is what I have saved in my notes:
sudo apt-get -y update
sudo apt-get -y dist-upgrade
sudo apt-get -y install libglib2.0-0 libflac8 libasound2 libasound2-data libgomp1
sudo apt-get -y install rygel
wget https://www.sonarnerd.net/src/stretch/libgmpris_2.2.1-4_amd64.deb
sudo dpkg -i libgmpris_2.2.1-4_amd64.deb
wget https://www.signalyst.eu/bins/hqplayerd/stretch/hqplayerd_4.10.2-29_amd64.changes
sudo dpkg -i hqplayerd_4.10.2-29_amd64.deb
hqplayerd -s hqplayer password
systemctl enable hqplayerd; systemctl restart hqplayerd
apt-get install alsa-utils
I also use Jussi’s custom kernel:
wget https://www.sonarnerd.net/src/stretch/linux-image-4.9.158-jl+_13_amd64.deb
wget https://www.sonarnerd.net/src/stretch/linux-headers-4.9.158-jl+_13_amd64.deb
dpkg -i linux-headers-4.9.158-jl+_13_amd64.deb
dpkg -i linux-image-4.9.158-jl+_13_amd64.deb
1 Like
Thanks! I forgot to start hqplayerd.service. Now is OK 
.
1 Like
First impressions about HQPlayer Embedded vs Roon on ubuntu server 18.04.2. Further differences from Roon:
- HQPlayer Embedded does not support a DHCP server in ubuntu; that is, it does not see an endpoint with a NAA connected to the second ethernet port; sees only across the network bridge;
- identical upsampling settings for all PCM regardless of the sampling frequency and for all DSDs;
- during PCM upsampling with sampling frequencies multiples of 44.1 to 705.6 (auto rate family option enabled) there is a crackle during playback, at 352.8 and at 768 (auto rate family option disabled) - no.
Hi Katun, what do you mean by this, in terms of a difference from Roon?
Which NAA are you using? And which DAC?
Can you share a screenshot of your HQPe config page showing all settings?
For example I can made such settings in Roon but not in HQP:
DietPi Nano Pi Neo 2 and DIYINHK USB/DIYINHK AK4493 dual mono DAC.
1 Like
This doesn’t have anything to do with DHCP server, it only has to do with your multicast routing rules.
Why don’t you have NAA on the regular network?
This case however automatically works if you boot up HQPlayer OS. For Ubuntu/Debian/Fedora you need to know how to set up network correctly for this case.
There are separate settings for PCM and DSD, and for 1x rates and higher “Nx” rates.
1 Like
HQPlayer doesn’t do that, because there’s no bounded set of possible input and output rates. How do you set things in Roon for upsampling for example from 123 kHz to 456 kHz?
1 Like
I upsample PCM 44.1 kHz to DSD256 and PCM 48 kHz to PCM 768 kHz in Roon DSP. How can I do it in HQP ?
1 Like
This makes no sense because there is no audio msic files with a sampling rate of 123 kHz in practice.
Well. I have an Intel NUC with an installed Ubuntu server 18.04.2 as a Roon Server. The native ethernet controller NUC is connected by a patch cord to a wifi router, the second external usb ethernet controller NUC is connected directly to the Roon endpoint (this is my ethernet DAC). Ubuntu has a DHCP server which creates a separate dedicated subnet only for communication with the endpoint isolated from the rest of the local network created by the wifi router. Thus the Roon Core - endpoint connection is isolated from the general parasitic traffic existing in the common local network and serves only to transfer musical information from the Roon Core to the ethernet DAC. This has a very positive effect on the sound quality. All this allows to make RAAT but does not allow to make NAA (HQP does not see an endpoint connected to the second USB ethernet port).
You cannot (except by switching manually), because that doesn’t make any sense.
I have bunch of files at 120 kHz sampling rate. There is also 32 kHz-based standard sample rate family with 32/64/128 kHz sampling rate. I have also a DAC running at 40 MHz sampling rate.
There is no reason to be constrained to few sampling rates. Best would be to optimize sampling rate and word length for each song specifically based on spectrum analysis of the content. I’ve done some of such and it works great for saving some disk space.
There is no need to isolate HQPlayer’s NAA traffic from other traffic. I have everything as single network (apart from couple of special purpose VLAN’s but those of course go on the same wires). Total six switches and four wireless access points. Having HQPlayer running on a laptop and playing 8 channel DSD256 over WiFi to a wired NAA works perfectly fine without any difference on sound quality.
If you have enough internet bandwidth and create a VPN, you could put NAA traffic travel over VPN tunnel to other side of the globe and still the sound quality would be the same. This is no different than playing something for example from a Tidal server (in such case, you have the stream mixed with lots of other people’s internet traffic).
What are the files? What’s music, what are artists, albums? Where you can buy or download them?
If you do not have a difference in sound quality then you really do not need “to isolate HQPlayer’s NAA traffic from other traffic.” But in my audio system there is this difference and not only in my system judging by the reports on audiophile forums. If you only focus on your needs when creating a product then everything is OK, if you want your product to have maximum demand then it is probably worth considering the opinions and needs of other users.
1 Like
I have created those with HQPlayer 4 Pro. But there are many other tools you can use for creating such.
If you are not happy with HQPlayer and consider Roon better, by all means use Roon instead.
Sounds like you didn’t even try NAA yet, only Roon Bridge (RAAT).
I just take objective approach. Overall, it would be preferable from my point of view, to use my products the way they are designed, tested and verified to be used, instead of something else (otherwise it is like buying a Ferrari sports car and then saying it doesn’t work great as off-road vehicle). I would be happy to see measurements of such traffic isolation making a difference. From electrical point of view, more hops you have on the network, more isolation barriers you get on the path from HQPlayer machine to the NAA. I have typically three switches on the way - that makes it 8 isolation transformers on the path.
There are also other typical mistakes that spoil the point of NAA entirely, like use of shielded (“audiophile”) ethernet cables.
Regarding Roon endpoint discovery vs NAA discovery. I think first of all Roon is still sticking to IPv4 only, while HQPlayer prefers to use IPv6. For discovery Roon is scanning network by knocking every host within the subnet. For IPv4 class-C subnet this is doable as there are only 255 possible hosts. For typical 64-bit IPv6 subnet it is not feasible given 2^64 possible hosts. I also don’t like idea of banging every host on the network. So instead HQPlayer relies on multicast-based discovery mechanism. Just like for example UPnP does as well.
Typically, multicast is routed where the default route goes unless something else is explicitly defined.
OK, Jussi. I keep testing HQPlayer .