HQP NAA - Raspberry Pi

Hi, I’ve been using the Raspberry Pi 2 image from the signalyst website which is NAA version 3.42. I see that the latest is 3.51. Can someone provide instructions to update to the latest version? I see above instructions for dietpi. Is that the basis for my image? How do I log in to get a command prompt?

Will the new version allow me to do DSD256 in non-DoP mode on an Auralic Vega?

Thank you!

Hi @RBM,
Sorry to be back on this old topic.
I’m feeding my DSD DAC from ALLO USBridge. Due to AMANERO FW limitation i’m only using DoP (DSD128).

According to NetData Ethernet bitrate is 11000 -13000 kilobits/s (1.6 MB/s max).
In my understanding DoP encapsulation is X2 bandwith VS native DSD. So using native DSD128 would be 0.8 MB/s, isnt’it ?

0ther USBridge users are reporting 46000 -50000 kilobits/s (6.3 MB/s) max) on DSD512 native.

Could you confirm or correct my understanding about DoP / Native DSD bitrate ?
Thank’s

I don’t see any RPi NAA build on the HQP site… am I missing something - thought this was mentioned so posts back. @jussi_laako

Will the NAA option in DietPi work for this? @Dan_Knight

NAA available from DietPi is perfect. No issue, very stable.
Using it since few months both on Sparky SBC (ALLO USBridge) and on stock RPI.
DSD512 bandwith handling is another story, i’ve not tested > DSD128 (DoP)

Interesting - I had been running a core on DietPi X86 on Debian AMD64 with an i5-6500 and even up sampling to DSD512 to a Ropieee based RPi with no issues - just to see if it worked.

Maybe that would be thinner than a windows based NAA on the same hardware. But running Ropieee with RAAT passing DSD512 (LAN connected) works fine and is my main rigs setup to an OPPO Sonica DAC.

Interesting ! But in case AMANERO FW issue fixed i would like to use USBridge (vs RPI) and i’m not sure it is OK due to Sparky HW or SW possible limitation … However seems other users succeed: https://www.computeraudiophile.com/forums/topic/32132-allo-sparky-usbridge/?page=45&tab=comments#comment-786123

I have a Sparky too…but its destined for VOLT deployment when I can get the failed Kali and Piano 2.1 replaced…geeze must get onto that - Been down for a few months now :frowning:

My bad !
Sorry, answers were already on this thread:

So DoP X2 bandwidth consomption is on USB, not on Ethernet !
Seems ROONBRIDGE act as HQP NAA. DoP handled at the endpoint side.

What gives you that impression? DoP is just native DSD with a PCM-cloak. The overhead must be minimal?

https://www.northstar.it/dsd-native-vs-dop/
http://dsd-guide.com/dop-open-standard#.WpAndBPOWRs

But adding 8bits to each ”packet” is not doubling the bandwidth? Most DACs that consume PCM also require/desire 24bits package sizes and the software/driver pads 8 useless bits in those cases too?

I agree Mikael. I’m not sure about maths on DoP X2 bandwith overload.
Perhaps some insights from @RBM or @jussi_laako ?

See also: https://www.computeraudiophile.com/forums/topic/27819-native-dsd-versus-dop-comparison/?do=findComment&comment=534000

DoP overhead is about 50% in terms of bandwidth compared to DSD native.

For example all XMOS implementations, and most other modern DACs USB interfaces use 32-bit samples (all modern DAC chips accept 32-bit PCM input too). DoP has 16-bits of payload per sample. Thus 50% overhead, where 25% is the marker byte (8 bits wasted) and 25% is zero-byte (another 8 bits wasted). XMOS and most other native DSD implementations utilize all 32 bits for DSD data, no markers and no zero-bytes. So for example with XMOS, to transfer DSD64 using DoP needs 176.4 kHz sampling rate (176400 x 16 = 2822400), while DSD64 as native DSD needs only 88.2 kHz sampling rate (88200 x 32 = 2822400).

3-byte (24-bit) sample formats are extremely inefficient to handle on modern computers and microcontrollers because it is not aligned to any native word length and needs to be handled as three separate bytes.

P.S. Note! With NAA, use of DoP or native DSD doesn’t affect network bandwidth usage. Network bandwidth is not wasted to transfer DoP markers and such. DoP is handled at the NAA side (when used). So DoP only affects the bandwidth usage to the last DAC step.

1 Like

@jussi_laako , Thank you for the maths and example … :smile:

I’ve got the Allo USBridge working perfectly fine at the moment with HQP DSD512 and DSD512x48 using the Allo supplied USB-ethernet adapter on Sparky’s USB2.0 port.

I have issues with DSD512x48 on Sparky’s ethernet port (stuttering). It’s ok with DSD512x44 but I need DSD512x48 working so I scrapped the idea of using Sparky’s on-board ethernet.

Like some others on the CA Forum I have issues using the Allo supplied USB-to-ethernet adapter on Sparky’s USB3.0 port.

But the USB-ethernet adapter works rock solid on the USB 2.0 port of Sparky.

I have USBridge is streaming to the new iFi xDSD (5Vdc externally powered). The USBridge is quite happy being powered by a USB3.0 port (900mA).

Tested with Roon + HQP (obviously) but also with mConnect and BubbleUPnP playing direct to HQP Embedded > USBridge NAA.

This is an important note by Allo for Roon + HQP:

A nice HQP NAA. Very smooth sounding USB source, which makes me think (guess) Allo pay attention to good RF filtering before the output.

1 Like

Hi. I have a diy dac with Ian fifo reclocker connected by i2s to Raspberry Pi 3+. with Volumio and other software works well with Hifiberry drivers, but when I install hifiberry drivers with Naa in any of the distributions for rapsberry, as explained here for functions with Hqplayer, it does not work. any advice?

Best regards.

Jorge

I tried to get the NAA daemon running on my dietpi. The service starts automatically but there is an ipv6 problem which is disabled on all nics. If i start networkaudio service with option ipv6=0 its working but how can i manage to get that started automatically?

Why do you have IPv6 disabled?

All my components are using ipv4.