NAA always has only single backend and I’m not eager to maintain two separate builds of networkaudiod for OS X. Especially since primary NAA platform is Linux because it can scale down so much more and can be fully customized to the bone for the purpose.
Hi Allen,
Good stuff! Any update on the stress testing you have done? I have been experiencing the same issue with my Devialet and the RPi2 NAA image from Jussi, so I may give this a shot.
Hopefully Jussi and Jesus are looking into this so that the RPi2 NAA image and the SOSE/MicroRendu software can be updated to fix this issue.
Best,
Peter
Hi Peter
I did re-image Stretch onto a new card, went through the whole process as outlined in other threads and added the NAA. I also make sure to try and check the install for any updates or upgrades (apt-get upgrade, apt-get update) on a weekly basis, and sure enough a whole batch loaded last week.
Anyway, stress of work is outbidding stress testing the set up, but fingers-crossed, the set up has been behaving reasonably well, i.e. I can turn my Dev back on the next day, and it is being picked up by the NAA. I will push the typical usage a bit harder when I can and try to make it trip over. Just typical ‘family’ usage is what I mean, switching inputs, pressing the power button, etc.
In the meantime, Jesus did respond to say he would look into USB disconnection issues, but no promises. As for Jussi, hmmmm, not much to report there, which is a shame really. His only guidance was to switch the whole lot on and off at the same time, as he does with his system. So, as far as being an early adopter of the microRendu, I might have to wait for others to put it through it’s paces and see whether that unit has any inkling of fussiness on the USB bus. Or fore-go HQP on NAA and wait for Roon to give us DSP enhancement.
This has been fixed with the latest version of NAA.
Are you sure? I just checked mine and it shows software version 2.1 (which it says is the latest), but every time I shut off the power to my DAC, I have to reboot the Sonicorbiter to have HQPlayer see the DAC. That is true even if I a) stop HQPlayer and b) switch HQPlayer to my other DAC (which is on all the time) before turning off the main DAC.
I haven’t tested it here. But the HQplayer people said it was fixed and another user confirmed it.
In the Sonicorbiter SE web interface go in to Apps -> Software manger and click update.
Then reboot and test again.
Interesting, although it showed that the software was the current version (2.1), when I did the update it actually updated a bunch of things. Haven’t had a chance to test it yet, but thanks for insisting that I do the update!
I just did the update and I can confirm that there is no difference. If I turn my DAC off and than back on, I have to also reboot the SonicOrbiter and also quit and relaunch HQPlayer, if not I just get HQPlayer with the spinning beach ball of death on my Mac.
Latest networkaudiod improving this behavior is version 3.2.1.
Does it show what is the networkaudiod version there, or is the 2.1 it? If not, the version can be found from HQPlayer log file…
Sonicorbiter is running NAA 3.2.1 that was released on March 14th 2016.
If you want to see what version you have you can go into the web interface an go to apps -> software manager -> Installed apps you will see version 3.2.1 next to HQplayer.
If you don’t press the update button.
Yes, it is NAA 3.2.1 but it still needs to reboot the SonicOrbiter and HQP when turing the DAC off and on.
If using RoonReady app, the SonicOrbiter does not need to be rebooted only when using HQP as the selected app.
Then it may be related to something else in SonicOrbiter, because it works for me on my own installations. When you hit play in HQPlayer, it will re-discover the DAC.
You need to have DAC available when starting HQPlayer or changing settings. Otherwise HQPlayer cannot know what formats the DAC supports. Without this information, HQPlayer cannot tell which formats you will be able to upsample to.
Some applications choose to fail when starting playback if the DAC doesn’t support format you are trying to play. HQPlayer doesn’t even let you attempt such.
Or they don’t display the DAC capabilities when you are not playing. As a result, they may let you try starting playback to something that is not available.
1 Like
@Jussi, An update on the SonicOrbiter this morning happened and now works perfectly when turning the DAC off and on while leaving the HQP app open and without having to reboot the SonicOrbiter.
Thanks for all the great work, this was the one feature I really wanted to work.
1 Like
Just downloaded and installed HQP 3.13.3 desktop and NAA 3.2.1 image for Cubox-i. Can swap between zones in Roon and change inputs on the DAC in any order without having to close HQP or restart the NAA.
Even tried playing to the HQP Zone in Roon before I had selected USB on the DAC. After swapping to the USB input on the DAC I had no music (as expected, the USB input doesn’t exist for anything until selected in the DAC). Reselecting the NAA device and output however saw music play to the USB input without having to restart anything.
Thanks Jussi !
Hi Andy
Which one sounds better on the cubox to your ears?
HQP or NAA?
I’m running HQP on a BRIX and sending the output to an NAA on the CuBox. The CuBox couldn’t run HQP, it can be pretty intensive. I’ve edited my post to be clearer.
Sorry, I misunderstood.
I thought you have a HQP NAA endpoint and the Roon NAA on the same cubox and can compare the two. That would be interesting…
It’s certainly possible to have a CuBox run both RoonBridge and an NAA. The Sonore SonicOrbiter SE does exactly that.
One day, in my dreams, I hope to be able to send HQP output to my Auralic Aries. I know it’s a smaller and more petty dream than world peace or universal respect for human rights, but it seems to have a similar level of diplomatic difficulty.
@jussi, @agillis This is now not working anymore, it’s just like before. I updated to 3.13.3 the other day and the latest update on the SonicOrbiter and since then the SonicOrbiter and HQP are acting just as before where you constantly have to quit HQP / reboot the SonicOrbiter when you turn off / on / or change the input of the dac… 5 days ago when I had 3.13.2 installed and whatever SonicOrbiter update on that date everything was working perfectly!.. I’m actually finding this VERY frustrating that things seem to constantly work one day and not work the next day.
When it comes to SonicOrbiter, you need to talk to Sonore. I don’t have SonicOrbiter myself, so I cannot inspect any problems with it.