Question regarding use of HQPlayer Desktop with Roon:
Is the stream from HQPlayer to the NAA endpoint using RAAT? Or some HQPlayer native protocol? My guess is it’s not RAAT since HQPlayer streams to NAA endpoints with or without Roon (and Roon endpoints don’t necessarily support HQPlayer).
Maybe getting off in the weeds here, but are there technical benefits to NAA over RAAT? Or are they similar?
Noted.
I wouldn’t think an ADI-2 with HQP OS chain would ever suffer in clocking issues. This is as perfect a combination as exists I had imagined.
Except maybe the T+A with built in NAA may be more optimal but even that has ethernet to USB i understand. It’s not ethernet direct to I2S/DSD.
I have to also test ADI-2 SPDIF “input” more also to see if the issue is just with UAC2 “input”. In my limited testing so far, ADI-2 SPDIF input doesn’t have this problem that UAC2 input has.
At least I’m happy fixed DSD rate works fine. I just need to get more powerful HQP machine where I don’t have to worry about auto family rate and CPU load.
Waiting for M1x Mac Mini news soon.
No…
Yes, it is HQPlayer NAA protocol.
I created NAA before RAAT even existed (or other network procotols like AES67 or AVB). It is designed for HQPlayer purposes, to minimize output noise, run on low power hardware, and not pose limitations for media formats, such as number of channels, sampling rate or PCM, SDM or such. And I’m freely able to extend the protocol the way I want.
For example recent addition was to support NAA on the input (source) side. I don’t think RAAT supports audio inputs at the moment.
Thanks for the info! I’m really enjoying getting to know HQPlayer and a little bit about how it works!
An update on the above previous discussion.
So I picked up a used RME ADI-2 DAC FS (the original AKM 4490) for cheap !
This is in anticipation (hope!) that Airplay will get an upgrade at some point in the next 12 months to support their own bloody Lossless Hires properly 
So for one week I’ve been testing it using UpBoard as NAA input.
When adaptive auto rate is enabled, definitely UAC2 input has the clock sync issues resulting garbled audio together with the music, when sample rates changing between x44.1k and x48k base rates.
And using ADI-2 spdif input - not a single problem at all.
The UAC2 input issue disappears when adaptive auto rate is disabled - so fixed output rate.
In both cases, the source is an iPad + Apple Music Lossless Hires. To get optical out of the iPad and into the ADI-2 I use my miniDSP USBStreamer with Apple USB3 camera kit adapter.
Anyway if you can fix the UAC2 input clocking issue that would be great for ‘completeness’ but if not I can just stick to fixed output rate.
So there’s something funky about UAC2 input specifically related to clocking that causes this issue , that ADI-2 SPDIF input doesn’t have.
I know you said you may not be able to do anything about this but I still wanted to compare properly.
It could be that something gets messed up just because reinitializing the DSP for rate conversion between rate families can take longer time, etc… You could try with different filter types, since they have hugely varying initialization times, etc. And also note that there’s now cache for the DSP initialization, so it takes different time on first change to a certain rate, but then next change to the same rate is faster, etc…
But certainly ADI-2 digital inputs work very well (a bit of setup effort though, because it cannot be preconfigured on the OS image). Now just convince RME to make a digital I/O device based on the same implementation (without ADC/DAC)!
Yes, only yourself to blame there !! Like the Spiderman meme 
I’m only joking of course. With your help I have now mastered it and can help anyone else that wants to try in future, saving you some time perhaps.
I should update my other thread about how to get Spotify/Apple Music/Deezer etc through HQPlayer, with the RME SPDIF input method.
I’ve changed the names of 2 of my NAA’s now even though I only needed to change 1 really. But good practise especially if I add another audio zone with another NAA. And while changing NAA names I added the ADI-2 serial numbers in the same step.
I guess the only inconvenience is when HQP OS gets updated, I need to repeat each time. But maybe not so often because I’m only using the NAA part of HQP OS, so don’t need to urgently update each time.
Yes true.
If they did make a DDC it would probably be the same price as this used ADI-2 (AKM 4490) I got that will pop up over time also… but yes with 2 x ADI-2’s on my desk it does visually look and “feel” like a waste to not be using the high quality D to A of one of them.
Curious why ADI-2 SPDIF input wouldn’t be affected by initialization time though? Only UAC2 input is.
So far with UAC2 input, when I get the garbled sound initially, I stop listening with UAC2 input. It’s not fun to experience on headphones. But I can re-try and see if sample rate changes over time start to work better, after that initial garbled sound event. As you say, maybe after that first time it doesn’t happen again. I will test.
No so bad for me with the ADI-2 Pro, since I’m “using” ADC too, leaving just DAC unused. Great for anybody with a vinyl rig and wanting to do some room correction for that side too.
Because ADI-2 happily throws away unused data coming in on S/PDIF. S/PDIF is kind of easy in that sense, sender side doesn’t even know if there’s a cable connected or not. But the UAC2 input thing is much more complicated. It may also depend on what OS / driver is on the host side for UAC2.
Long term testing, even without any upsampling, has same issue. Still only any issue with auto family rate. Not an issue with one fixed output rate.
Last year you mentioned RPi4 UAC2 input would come ‘soonish’. I’d be keen to see if that’s any different to UpBoard behaviour. Have you been able to test RPi4 with UAC2 input yet?
Also how would you be able to power the RPi4 if the USB-C port is used for the UAC2 input?
No, been busy on other things… Maybe someone else could try it out?
From the computer’s USB port, just like any other USB powered device would be.
I can try but with UpBoard you were able to guide me with the BIOS settings that needed to be changed for the input feature to work.
I have no idea if RPi4 needs something similar changed?
Noted but UpBoard Gateway can’t be powered by a USB 2.0 port (0.5A only).
Whether RPi4 can be (properly) powered by USB 2.0 or 3.0 port… I guess I’ll try and report back !
@jussi_laako I just tried it.
I don’t get the “Playback inactive” showing as a USB soundcard in macOS, the way it does with UpBoard.
I don’t get any kind of HQPlayer related USB soundcard showing.
Using the UAC2 input with the latest HQP OS.
See below screenshot
It may need something to enable OTG functionality. Or maybe not, I haven’t got time to look into this particular aspect.
Yeah, but we are talking about RPi4 here…
USB 3.0, or Type-C. USB 3 SS port can feed 900 mA. Type-C can deliver up to 3 A.
There are no available USB Device Controllers which makes things fail. But it is progress already.
Yeah, as it’s not tested, it is not included in the default hqplayerd.xml
I know but when you mention “just like any other USB powered device would be.” USB 2.0 port doesn’t work with UpBoard, so need to mention USB 3.0 or Type C port (at the USB audio source side which is where the RPi4’s power needs to come from).
Just tested, USB 3.0 port on my Mac works, using Type A to Type C cable.
Mmm possibly. Nothing else I can try really so I’ll just wait till you try it one day.
Regarding UAC2 input of UpBoard Gateway, I see another user mentions it needs fixed output sample rate. So auto sample rate switching is not reliable for him it seems:
HQPlayer USB class 2 input (NAA, HQPe) - Software - Audiophile Style
Good to know my testing results is consistent with someone else.
He also mentions some UAC2 fixes with Linux kernel - do you think that could be related or un-related to this problem with HQP UAC2 input?
Yeah, because he’s not using my UAC2 support but instead Linux kernel’s UAC Gadget.
Ok interesting. Yours is still broken for me anyway though (just auto sample rate switching).
I never had any issues pre-ROCm support though.
UAC2 input used to be flawless.
Then it got broken, then I reported it broken, then you fixed it with seperate x64gen build.
But that auto sample rate switching part is still broken. Something is still different to how it used to work well.
HQPlayer OS doesn’t have CUDA or ROCm support though…
With poly-sinc-ext2? Or are you using some filter that didn’t exist earlier?
