Jump to content
IGNORED

HQPlayer's Network Audio Adapter


Recommended Posts

12 minutes ago, Em2016 said:

USBridge was mostly fine for me - if it's working for you, just don't ever do a DietPi update, unless you're prepared for things to go wrong and you need to do a clean install. Which means you need to open the thing and take the eMMC out etc.

 

I have read that the problems may arise from GUI updates. It seems that console updates work fine.

 

Link to comment
2 minutes ago, Em2016 said:

 

Good point. Yes the web GUI image version caused me and others most issues.

 

The normal Sparky image (on DietPi website under Sparky) has been better for me.

 

 

I have ordered one USBridge (DietPi version) a couple of days ago, so I have not tested any yet. I guess, that even the USBridge preloads a GUI version, the console can be still used, right?

 

There is a procedure in Allo website that describes the steps to flash the eMMC with a new image.

Link to comment

This weekend I have been testing an Allo USBridge that I had ordered. The USBridge came with Allo DietPi 6.1 installed and ready to run. This DietPi run Roon Bridge, Signalyst NAA and other media software simultaneously. I disabled most of this software but let running Roon Bridge and NAA.

 

I configured my HQPlayer Embedded 4.7.1 to point to the new USBridge and did not configure anything else. I tested and it worked at the first try. Nice!

 

After this first test, I updated HQPlayer Embedded to version 4.8 and USBridge's DietPi to 6.19. The update process for the USBridge was long due to it patches every single version from 6.1 until 6.19, but eventually it ended. I tested the system again and it still worked. Nice again!. By the way, I updated DietPi from the console not from de GUI.

 

After that, I thought of testing the Roon Bridge from Roon, I don't know why, but I did it, perhaps just for fun and see if I could send a stream from Roon Core to the same USBBride (and the same DAC) alternatively to USB Bridge and NAA. Well, it worked too, but... oh surprise!!! When I was streaming to Roon Brige, I noticed that my Rotel RC-1590 display showed "DSD" instead of "DoP". So I went quickly to the HQPlayer Embedded config page and unchecked the DoP option and... HQPlayer Embedded (through NAA) also played in native DSD with an Allo USBridge.

 

That's nice for me because this way, I avoid that ugly pop sound every time I start playing DSD and stop playing, due to the change in the DAC between DSD and PCM.

 

I don't know if this posibility to use native DSD is due to DietPi version, Allo DietPi, or.... I don't know, but I am happy with this.

 

In the next weeks, I will test too an UP Gateway, recommended by @Miska. I will test it running Debian Linux and installing the networkaudiod and I am going to test it with the HQPlayer OS image. And the question here is: Will I be able to play native DSD too with UP Gataway and any this two software configurations that I am going to test?

 

Link to comment

Hi @Miska, for you information, I have detected a small issue with HQPlayer Embedded and NAA. Not a big deal for me, I can live with it. I just tell you in case it is interesting for you.

 

When I click play in Roon, but only the first time I do it after executing Roon, the stream to HQPlayer Embbeded and NAA, does nothing and after a few seconds I get the message "Roon lost control of the audio device", but then I can click again and it works with no problem all the time until the next execution of Roon.

 

My current setup is Roon Core and HQPlayer Embedded run in a NUC with Debian 9. The NAA runs on a USBridge with DietPi 6.19.7.

 

The DietPi runs Roon Bridge and NAA at the same time. I disabled Roon Bridge but it made no difference. I also changed the value of the parameter aotg.urb_fix from 1 to 0 in /DietPi/uEnv.txt, but it did not work either, so I rolled it back to 1.

 

As I said, this is not a big deal for me. If you need any log or further information, just ask to me.

 

Link to comment
22 hours ago, Miska said:

Logs from hqplayerd and networkaudiod would probably help.

 

Hello @Miska.

 

This afternoon I have enabled the logging facility both at HQPlayer Embedded and NAA. Today the things go right. "Bad luck".

 

Anyway, I have left enabled the logging. As soon as I detect it, I will send you the logs.

 

Link to comment
7 hours ago, Miska said:

 

Looks like on the first attempt the NAA was disconnected for some reason and that's why it failed. HQPlayer log doesn't go far enough back to have the initial discovery and connection.

 

Thanks @Miska. I will do some research with that. Perhaps it has to do with something specific to USBridge's DietPi. We'll see.

 

USBridge's DietPi runs Roon Bridge and NAA at the same time. It seems it is not a big deal. Just in case, I disabled Roon Bridge but there was no difference at all. So I have enabled it again and I also enabled it as an output at Roon Core, just as a backup output for DSD.

 

 

Link to comment
6 hours ago, luisma said:

Do you turn off your dac @acatala?

 

 

Yes, I do. The DAC is built-in the preamplifier (Rotel RC-1590) and I either power it off of put it in stand-by from the remote. The lattest times I am using the remote.

 

As I said before to @Miska, Roon Bridge and NAA run simultaneously and this behavior happens with NAA. I will try to find out why NAA seems to be "sleeping" the first time I try to play music.

 

Link to comment
  • 3 months later...

Hi @Miska,

 

in the first place, thanks for your adjustments in HQPlayer OS 4.10.x that let Rotel RC-1590 (AKM's AK4495 based) play native DSD. I appreciate it very much.

 

I am currently booting my UP Board from a USB drive but now that the DSD issue is solved, I am going to write the image in the internal eMMC drive. So I wonder if I would better write a simple NAA image instead of a HQPlayer OS image. I am going to use the NAA function (Ethernet to USB bridge only). If NAA would boot faster than HQPlayer OS, which I don't know, I would not get any advantage by booting the latter.

 

If NAA would be the fastest option, we would need a NAA modified image with the adjustments included, right?

 

By the way, I am still using HQPlayer Embedded 4.9 in the NUC and HQPlayer 4.10.0 in the Up Board. I will update both this weekend to 4.10.2, or the version available at that time.

 

Link to comment

OK, thanks @Miska

 

28 minutes ago, Miska said:

 

NAA image runs from RAM, so it likely doesn't get broken even if you pull the power randomly (HQPlayer image shouldn't either though).

 

That feature interests me. It's nice just pushing the power button to power on/off and forget about shuting down.

 

31 minutes ago, Miska said:

Another difference is that HQPlayer image runs multiple network interfaces in bridged setup.

 

I only use the Ethernet interface, so from this point of view it does not apply to me.

 

33 minutes ago, Miska said:

You can also disable HQPlayer startup from the image with command "systemctl disable hqplayerd" which will make the HQPlayer image boot even faster. 

 

It would be a nice option too, indeed, but I should run the shutdown command or leave the NAA powered on. I can consider this option too.

 

41 minutes ago, Miska said:

I can try to update it some time soon, for example next week

 

Thanks. I am not in a hurry. Currently it works and works well, so no problem at all.

 

Link to comment
15 minutes ago, Miska said:

 

Short push of power button (the type of soft button that most computers have these days) triggers normal shutdown on HQPlayer image as well...

 

 

You can check if the power button triggers normal shutdown. But at least my HQPlayer Embedded and NAA computers all work that way. So I just push button to power up and then push the button again to power down. Never have to deal with shutdown commands...

 

 

The power supply (LPS) is external, so it powers off the hard way 😀. No option for soft button push.

 

I will issue shutdown commands when I have to. For convenience I was thinking of building a homemade web page in order to shutdown my different end points by just clicking a button on screen. I would parametizer every button in order to send the appropiate shutdown command to the intendend endpoint.

 

I will work on this when I have a few time. Perhaps it would be a fancy feature for HQPlayer Embedded too. I will let you know.

 

Link to comment
3 hours ago, Miska said:

 

OK! :D

 

UPBoard has the button, but if you have the standard passive cooled case for it you need a small tool to push it...

 

 

I didn't see that power button. It seems easy to push with a simple tool. I will use it. Thanks!!

 

Link to comment
On 5/29/2019 at 12:39 PM, Miska said:

 

The two images are mainly different in the way they run. NAA image runs from RAM, so it likely doesn't get broken even if you pull the power randomly (HQPlayer image shouldn't either though). But due to that, it boots quite a bit slower than HQPlayer image since it needs to load entire filesystem to the RAM at once.

 

Another difference is that HQPlayer image runs multiple network interfaces in bridged setup, while NAA image doesn't create any bridge and assumes just one ethernet interface being in use. So the NAA image has lower CPU load/traffic for networking functions.

 

You can also disable HQPlayer startup from the image with command "systemctl disable hqplayerd" which will make the HQPlayer image boot even faster.

 

 

Yes, I can try to update it some time soon, for example next week. Ping me if it doesn't appear by end of next week...

 

 

Hi @Miska

 

I have downloaded the new NAA image and installed it in a USB stick. 

 

Native DSD works now with the new image. Thanks!!!

 

I have measured boot times (from power button push to see DSD in Rotel display. The measured times are:

 

HQPlayer image with hqplayerd enabled: ~33 seconds

HQPlayer image with hqplayerd disabled: ~30 seconds

NAA image: ~37 seconds.

 

I guess I will stay with NAA image because I can just push the power button freely 😁. Besides, perhaps if use internal eMMC drive instead the USB stick, it could boot even faster.

 

 

Link to comment

@Miska,

 

my Up Gateway now boots the NAA image version 3.5.6.1 from the eMMC drive. The boot time is ~33 seconds.

 

The procedure was quite simple:

 

I prepared a microSD card + USB adapter in wich I copied with Rufus a Debian Live image.

I downloaded de compressed NAA image. After that I uncompressed it and copied it in my NUC running Debian. This is the NUC where Roon Core and HQPlayer both run. I copied here for convenience, so I can use scp from the Debian Live.

I booted the Up Gateway with de Debian Live image and run:

scp root@ip_nuc:/root/naa-3561-x64.img . (do not forget the final point!)

 

Then I executed:

sudo dd if=/root/naa-3561-x64.img of=/dev/mmcblk0

 

After a few seconds the NAA image was ready in the eMMC drive. Then, with the USB still inserted, I booted again the Up Gateway and went into the BIOS and set the eMMC as the boot device.

 

That's all!

 

 

Link to comment
  • 4 months later...

Yesterday, I installed the NAA 3.6.0 image on my Up Gateway's eMMC drive. The install process is simple ( https://audiophilestyle.com/forums/topic/13649-hqplayers-network-audio-adapter/?do=findComment&comment=964209 ).

 

So far, I have not found any issues. I can still play native DSD and it seems it fixed the annoying problem with the shutdown process of the networkaudiod that went into a blocked state for a couple of minutes before closing. Now the shutdown process (after pushing the reset button) is a matter of seconds.

 

The "double play click" is still present. Perhaps this is a specific issue between networkaudiod and the chipset of my DAC, I don't know. But after clicking the play control for thr fist time after powering on the system the music doesn't start, but it does after a second click. After that, it works fine.

 

In either case, NAA is better now.

 

Link to comment
On 10/8/2019 at 2:24 PM, Miska said:

 

If the DAC disappears from USB when powered down (not all DACs do this, since many power the USB interface itself from the USB bus power), ALSA driver doesn't report this to the networkaudiod immediately, it only fails in obscure ways when next time accessed. This is not a problem if HQPlayer is not connected to a NAA, because networkaudiod is hooked to the DAC only as long as HQPlayer is using it.

 

Thanks for your extended answer, @Miska.

 

The scenario is this: Roon and HQPlayer Embedded run 24x7 on a Intel NUC Debian 9 box, NAA runs on a UP Gateway with your NAA image and is attached to the USB port of the embedded DAC in the preamp.

 

The power on cycle is:

Roon and HQPlayer ar 24x7, so no need of power them on most of the time.

Power on DAC (actually preamp + amp)

Power on NAA

 

The power of cycle is:

Stop playing Roon (+ HQPlayer Embedded)

Shutdown NAA (Reset button pressing) + Power off it

Power off DAC (Preamp + amp)

 

The NAA is powered off before the DAC and yet the next time I play from Roon + HQPlayer Embedded I have to do the double play. Even, some times, the NAA remains running 24x7 a couple of days and I power off the DAC (preamp + amp) in the mean time and the behaviour is the same: I need the double play. In this case, the NAA doesn't fail even the DAC is powered on after him, I only have the double play issue. Weird, isn't it?

 

On the other hand, the rest of the system seems solid rock and I have no further issues. Nice sound quality, easy to update, a bunch of configuration options... in short: happy with the duet Roon + HQPlayer Embedded.

 

 

Link to comment
  • 3 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...