HQP NAA - Raspberry Pi

OK… That one should just boot, connect to your DAC and present itself to HQ Player.

No option (or need, for that matter) for logging in – it should ‘just work’.

What would you need to log in for?

I didn’t even try it that way…doh. I had it just hooked up to a monitor so saw the login and though I needed to. Did what you said and just looked in Hqplayer and it was there independent of loging in. Thanks for helping with the rookie.

Great! And now for some music… :wink:

Love this forum. I was just testing getting it onto my Pi2 since its been a while (piBaker saves the day again), but as I don’t even have a DAC or HQPLayer where I am right now, I thought I’d log in and have a nose at the settings/configs. After a few failed attempts, this has saved me any further time wasted! :wink:

Hi.

I don’t really know why I won’t let it go and just accept that the Pi will never be a good NAA (at high bitrates)?
So I did a new little experiment to see if adding an external USB3>Gigabit Ethernet NIC adapter to my RP2, would somehow fix the problem…It didn’t :frowning:
I had to install a new Debian Stretch distribution to test this, since the new NIC gets the name Eth1 (the build-in NIC is called Eth0). I haven’t yet figured out how to modify files inside Jussi’s precooked images.

The first song I listened to was a Sting tune at DSD64 converted to DSD256…Not a single audible click…Pure joy.
…then on to some regular Redbook converted to DSD256…and the clicking noises were back. Goddamned !!!
A little strange why the DSD64 song didn’t produce clicks?
I would expect that the amount of data received at the NAA at DSD256-rates would be just about the same no matter what the source material was.
Another strange observation: DSD5v2 256+fs and DSD7 256+fs Sigma Delta Modulators seems to produce far more clicking noises. Again…why when the amount of data “hitting” the NAA should be the same?

I still would like to test a few USB-driver tweaks, but I’m really not too optimistic right now.
Somebody…give me new hope !!!

1 Like

The main problem with the Pi is that the NIC shares the USB(2) bus, so adding a faster network adapter will only saturate the USB bus faster, I’m afraid – making a bad situation worse.

Not all DSD256 output is equal, I guess: the last mile to my NAA is wireless (really no neat option for cabling at this location, and just image what running a bare wire through the living room will do to your marriage…). I find that with some of the tougher filters (poly-sinc-without-2s for instance), I needed a little buffer set in HQP to avoid hiccups. Most probably networking-related though.

My NAA is a Cubox and it’s running just fine. I experimented with a Pi last weekend, but is was a clickfest at DSD128/256 and PC384 in any circumstance, wired, wireless and regardless of filter choice. I’ve got another Pi running Squeezelite though a Digiberry Digi+ (SPDIF coax) to my Meridian DSP5200’s – that one is brilliant: stable and just sounds great.

I too have a pi running picoreplayer (squeezebox clone) with an iqaudio dac and Roon runs brilliant thro this. No pops, buffering or anything.

The hqplayer thro pi as naa is to much of a PITA sometimes so if I really want to use HQP I just direct connect my macbook.

Most of the time tho picoreplayer is easily good enough.

Only USB-connected devices will cause problems with the Pi – I’m sure your IQAudio DAC performs most handsomely. :slightly_smiling:

BTW: Gordon @ IQAudio has a release candidate RoonReady image available for download – have you checked it out already?

I have Rene. I’ve given Gordon feedback on it.
Everything worked perfectly.

Bang for buck I really don’t think you can beat the pi and the iqaudio dac.

The iqaudio dac and amp is even better value.

Yes, the higher rates on USB audio cause problems. I’m at the moment playing with 192k upsampling to RPi2 plus HifiBerry DAC+ Pro boxed into the HifiBerry black steel case using my RPi2 NAA image and it works fine without any issues.

Connected to the DAC+ Pro is Schiit Magni headphone amp. Truly budget network audio endpoint! The combination is pretty much as inexpensive networked DAC one can get. The entire bundle is about 120€:
https://www.hifiberry.com/product/dac-bundle/

1 Like

@RBM
Yeah, I’m aware of the shared USB-bus issue but also that the USB-Dac problems have actually been a lot worse a few years ago. Here there were many rapports of click and pop noises when feeding USB-Dacs with 24-bit/96-192KHz pcm signals or even with regular Redbook.
These problems seems to have been largely solved, by various means. One was a rewritten RP USB-driver. This driver also have a few other settings which are not enabled by default, to handle problems with high bitrate audio. I tried to enable these but there was no change.

Many have also rapported success with altering the dwc_otg.fiq_fsm_mask=0x[X] setting in the /boot/cmdline.txt file
I have tried a few of these, especially the 0x7 and 0xF values but so far none of these have completely removed the issues for DSD128+

Maybe there just are no solution on the humble Raspberry Pi’s because of hardware constrains, but then again maybe a small change could tip the balance. I think we are almost there, since the clicking only happens with several seconds in between.

My other point was that is is strange that the amount of clicks can vary by altering other factors earlier in the chain.
I still stand by that the number of USB interrupts on the Pi running the NAA, will be the same whatever the Modulator type on the HQP is using, when outputting the same rate (PCM/DSD). It should not matter to the NAA whether the bits are 0 or 1 since where are all retransmitted to the Dac uncompressed.

1 Like

I know its not specifically relevant to HQP NAA, but when I was experimenting with my Pi2 last year, I found I got pops and crackles with squeezelite, but it was rock solid with Volumio. Same files, same source, same DAC, same network.

Volumio didn’t do what I needed ultimately and so I gave up, awaiting Roon’s solution. But unless I got lucky, it would seem that its not all down to the hardware - so dont give up!

I didnt have any DSD at the time though so 24/92 would probably have been the hardest test for it.

In my testing, it has been fine up to 192 with squeezelite and HQP through USB.

The pi as naa works awesome for me, but then it feeds my Meridian G68 at a measily 96K.

Volumio is rock solid, in my experience. I am running it on a Cubox-i4Pro with an Apple Airport Express as a wireless bridge (near WAP, strong signal). I can stream 192/24 tracks via uPnP with MinimServer with no issues at all. I had less luck with HQ Player’s NAA image on the same device - would drop off the network.

If some RasPi player application caches the entire track to RAM before playing back, things probably work better, since the USB connected network is not simultaneously in use in such cases. And if you play for example 192/24 FLAC tracks with UPnP or similar player it is yet again another matter because the content travels network in FLAC compressed form so the overall bandwidth usage is lower. Then you trade CPU usage for network bandwidth.

However, NAA is not a player application, it is just an audio endpoint. So you are not comparing equivalent things…

As I stated in earlier message, I have no problems running RasPi2 + HifiBerry DAC+ Pro at 192/24 as a NAA. The issue with RasPi has always been the combined bandwidth usage of network + USB audio since both share the same USB bus with internal bandwidth limitations.

Fair enough. For completeness, however, I will note that I have Volumio’s Audio Buffer set to 2048 KB (i.e. about 12 seconds of 44.1/16 audio) and I set Buffer Before Play to 30% of that value, so roughly 4 seconds of audio. Volumio’s mpd + upmpdci is hence only buffering about 4 seconds of audio, not the whole track. You can hear this, as playback starts immediately.

And overall it is transferring FLAC compressed content over network?

NAA doesn’t try to to optimize network bandwidth, but instead tries to optimize CPU load. So the NAA device is supposed to have a proper ethernet interface, preferably with hardware offload for TCP/IP checksums and zero-copy DMA, etc.

So, would this include the devices for which you provide bootable images? I am using one of these, not a DYI solution.

I know some of these devices, like my Cubox-i4Pro share the Ethernet device with the USB device (i.e. same controller), which might create a bottleneck or mandate additional CPU overhead with TCP functions implemented in software.

I’m definitely not trying to start anything, but I think even with raw PCM at 192/24, you wouldn’t need anything more than 16 Mbps. And, FWIW, I’ve run Volumio with 192/24 WAV (i.e. uncompressed) files with the same, result - flawless playback with minimal buffering.

I don’t particularly want to provide any images. For x86 hardware it is better to just take bare bones Debian Stretch, since supporting all the possible wide variety of hardware is too much pain for me.

For couple of specific ARM boards, I do build images because especially earlier normal OS installation was quite a bit more difficult than on x86 platforms and because the hardware is well defined and known to very limited number of configurations.

No, CuBox-i4Pro has gigabit ethernet straight inside the i.MX6 SoC on a high speed local bus. It is limited to about 400 Mbps in practice, so you don’t get full gigabit speed from it. It also has IEEE-1588 (PTP) support, so one can implement AES67/RAVENNA on it. It support Linux NAPI interface and has hardware checksum offload.
http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors-based-on-arm-cores/i.mx-6-processors/i.mx6qp/i.mx-6quad-processors-high-performance-3d-graphics-hd-video-arm-cortex-a9-core:i.MX6Q

Here is output of “lsusb” on my i4Pro with iFi iDSD Nano connected:
root@cuboxi:~# lsusb Bus 002 Device 002: ID 20b1:3008 XMOS Ltd Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The AM33xx used on BeagleBone Black also has gigabit ethernet controller straight inside the SoC on a local bus. It also has fairly elaborate DMA engine and also supports PTP.
http://www.ti.com/product/am3358

Biggest pain with USB-connected network gear is double-packetization needed requiring extra work from CPU.

I don’t know, same NAA software module on same OS works on other hardware platforms. And also in RasPi2 when used with audio devices on the internal I2S bus instead of USB. Generally hardware design where USB bus is shared for things like networking is not very useful for NAA. And such problems with NAA indicate that the hardware is not really up to the task, even if it would be possible to make it work somehow.

I have device with 400 MHz ARM9 CPU and 256 MB of RAM and it runs Linux just fine and can do stereo DSD256 without problems. It also has ethernet integrated straight into the SoC.