HQPlayer Linux Desktop and HQplayer embedded

[acatala]

On 7/7/2019 at 10:19 PM, Miska said:

 

It could help, some DACs unfortunately mess with the USB when they go standby. Then ALSA fails when rug is pulled under the feet (disappears while in use).  While they should keep the USB controller powered as long as VBUS on the USB is on. For example Holo Audio DACs and at least some Schiit devices operate correctly and the USB stays alive as long as VBUS is there even if the device is otherwise standby.

 

 

I rescued my USBridge and connected it to my DAC/preamp instead of the UP Gateway. I also reconfigured Roon to upsample to DSD128 and used it instead of HQPlayer for a few days. I have not experienced any issues the days by using Roon -> RAAT -> RoonBridge (over DietPi on USBridge) -> DAC. It didn't fail a single time.

 

There was two differencies from my former setup with HQPlayer: USBrigde vs Up Gateway and RoonBridge vs NAA. So, yesterday I went back to HQPlayer but this time I used NAA over DietPi on the USBridge. But I found the same issue with HQPlayer: The first attempt failed. I tested the same conditions on both setups.

 

I like HQPlayer, but I have to choose between live with the first attempt fail or use Roon as DSP too.

 

I think it would be interesting to improve the discovery protocol between HQPlayer and NAA so it would be more resilient. HQPlayer is great doing its job, it just needs to improve a few functional aspects.

 

[Miska]

13 minutes ago, acatala said:

I rescued my USBridge and connected it to my DAC/preamp instead of the UP Gateway. I also reconfigured Roon to upsample to DSD128 and used it instead of HQPlayer for a few days. I have not experienced any issues the days by using Roon -> RAAT -> RoonBridge (over DietPi on USBridge) -> DAC. It didn't fail a single time.

 

There was two differencies from my former setup with HQPlayer: USBrigde vs Up Gateway and RoonBridge vs NAA. So, yesterday I went back to HQPlayer but this time I used NAA over DietPi on the USBridge. But I found the same issue with HQPlayer: The first attempt failed. I tested the same conditions on both setups.

 

NAA is different from RoonBridge and HQPlayer is different form Roon. Roon goes for convenience while HQPlayer is no compromise for quality.

 

15 minutes ago, acatala said:

I like HQPlayer, but I have to choose between live with the first attempt fail or use Roon as DSP too.

 

Other alternatives:

1) Skip NAA and go directly from HQPlayer to the DAC, massively smaller change than switching over to Roon DSP.

2) Get a DAC that doesn't mess with USB all the time

3) Get a DAC that has NAA built in (this is how NAA is designed to be)

 

17 minutes ago, acatala said:

HQPlayer is great doing its job, it just needs to improve a few functional aspects.

 

Or the hardware used needs to improve it's functional aspects.

 

For example switching my Holo Spring DAC between standby and on, or Schiit Jotunheim, doesn't make any difference on the USB. You can happily play music also when the DAC is in standby. Just no sound comes out.

 

[PPk]

I'm trying to do bit perfect output via hqplayer 4. i notice it will always convert to 24 bit unless i manually set the dac to 16 bit. 

 

how do i set the behaviour where it will follow the bit setting of the incoming source? 

 

let's say when roon feed a 16 bit audio, it will output 16 bit to DAC

roon feed 24 bit audio, it will output 24 bit to DAC

 

thanks in advance for the help!

[mvilla]

4 hours ago, Miska said:

3) Get a DAC that has NAA built in (this is how NAA is designed to be)

 

Hi Jussi,

can you give just some example of DAC with NAA built in?

does it also mean that you can use your HQP on that FAC?

Thanks

Massimo

[acatala]

5 hours ago, Miska said:

Other alternatives:

1) Skip NAA and go directly from HQPlayer to the DAC, massively smaller change than switching over to Roon DSP.

 

Not an option

 

5 hours ago, Miska said:

2) Get a DAC that doesn't mess with USB all the time

 

Not an option

 

5 hours ago, Miska said:

3) Get a DAC that has NAA built in (this is how NAA is designed to be)

 

 

Not an option

 

5 hours ago, Miska said:

Or the hardware used needs to improve it's functional aspects.

 

 

... in order to deal with NAA.

 

 

[Superdad]

3 hours ago, mvilla said:

Hi Jussi,

can you give just some example of DAC with NAA built in?

does it also mean that you can use your HQP on that FAC?

Thanks

Massimo

 

Per the Signalyst.com web page, there are now two DACs available with NAA built in:

The $26,000 T+A SDV 3100 HV (https://www.ta-hifi.de/en/audiosystems/hv-series/sdv-3100-reference-streaming-dac-preamp/)

and the $6,200 TotalDAC d1 Streamer (http://www.totaldac.com/D1-streamer-eng.htm)

Not exactly within the budget of the everyman. 

[Miska]

2 hours ago, acatala said:

... in order to deal with NAA.

 

Why would NAA need to be adopted to deal with problematic hardware? I know Roon has lot of hacks to work around or hide problems of flaky hardware. But I don't want to go on that path.

 

[Miska]

7 hours ago, PPk said:

I'm trying to do bit perfect output via hqplayer 4. i notice it will always convert to 24 bit unless i manually set the dac to 16 bit. 

 

how do i set the behaviour where it will follow the bit setting of the incoming source? 

 

let's say when roon feed a 16 bit audio, it will output 16 bit to DAC

roon feed 24 bit audio, it will output 24 bit to DAC

 

That is not supported and outside of HQPlayer's scope. HQPlayer is all about the DSP algorithms. If you want to do that, you don't need HQPlayer.

 

HQPlayer is improvement/replacement for resource constrained DSP algorithms inside a DAC. And the purpose is to feed DAC at the single format it performs best at.

 

[mvilla]

1 hour ago, Superdad said:

Per the Signalyst.com web page, there are now two DACs available with NAA built in:

The $26,000 T+A SDV 3100 HV (https://www.ta-hifi.de/en/audiosystems/hv-series/sdv-3100-reference-streaming-dac-preamp/)

and the $6,200 TotalDAC d1 Streamer (http://www.totaldac.com/D1-streamer-eng.htm)

 

Thank you. superdad. 

 

[Miska]

1 hour ago, Superdad said:

The $26,000 T+A SDV 3100 HV (https://www.ta-hifi.de/en/audiosystems/hv-series/sdv-3100-reference-streaming-dac-preamp/)

and the $6,200 TotalDAC d1 Streamer (http://www.totaldac.com/D1-streamer-eng.htm)

Not exactly within the budget of the everyman. 

 

Companies using for example Streamunlimited or Conversdigital solutions in their devices likely won't see NAA support. Because there's not enough demand for such features and the two companies likely also see me as a potential competitor...

 

Companies who do their own solutions can usually fairly easily add NAA support. Others are on the mercy of the solution vendor.

 

[Miska]

By the way, HQPlayer OS >= 4.11 contains connection handling improvements on both HQPlayer and NAA side. The NAA side changes have not yet reached other packages.

 

[Superdad]

25 minutes ago, Miska said:

By the way, HQPlayer OS >= 4.11 contains connection handling improvements on both HQPlayer and NAA side. The NAA side changes have not yet reached other packages.

 

Are you referring to HQ Player Embedded?  And are these improvements only for those running your Linux package?  

I am running HQPe under AudioLinux (more control over certain OS things and @lmitche is my Linux guru making it all work for me with network shares; BTW, I will be paying for my HQPe license soon).

Can you tell us more detail about what these connection handling improvements are?

 

Also, I know you use Ethernet pause-packets/flow-control with NAA.  But seems like you only do so for Gigabit connections.  Is that correct?  And are pause-packets/flow-control used with all NAA platforms? I know for Linux, but are Windows and macOS NAA the same?

 

Thanks very much,

--Alex C.

[acatala]

8 hours ago, Miska said:

 

Why would NAA need to be adopted to deal with problematic hardware? I know Roon has lot of hacks to work around or hide problems of flaky hardware. But I don't want to go on that path.

 

 

Hi @Miska, it's fine that way. HQPlayer is your product and you know better than anybody the path to follow with it.

 

As a costumer, I currently have a number of options to play music with my systems, all of them already paid, so I won't have extra costs. All of them will let me listen to music with high quality and all of them are valid to me.

 

DSD from HQPlayer, from Roon or PCM (upsampled or not) to a DigiOne, all of them sound great. Everyone of them has its strengths and its weaknesses, but all work for me. I am a happy user.

 

 

[Miska]

23 hours ago, Superdad said:

Are you referring to HQ Player Embedded?  And are these improvements only for those running your Linux package?  

I am running HQPe under AudioLinux (more control over certain OS things and @lmitche is my Linux guru making it all work for me with network shares; BTW, I will be paying for my HQPe license soon).

Can you tell us more detail about what these connection handling improvements are?

 

NAA functionality was updated along with the HQPlayer Embedded release on the HQPlayer OS image. I have not rebuilt all the networkaudiod packages for other OS. I think I versioned the new one as 3.5.7. If you want latest everything, just use the HQPlayer OS.

 

In my opinion you don't need more control over certain OS things because the HQPlayer OS is purpose built for this particular purpose. No fiddling needed.  You can of course put HQPlayer Embedded on something else too, but I only test things to work as designed on the specified platforms (assuming use of my kernel where applicable - that is Ubuntu and Debian, on Fedora you get bleeding edge upstream instead). Otherwise there's a risk that something doesn't work as designed, this is especially critical for things like internal work load distribution and prioritization on multicore/multisocket CPUs.

 

Yes, I may be annoying with this stuff, but you wouldn't believe how much I spend time on testing and making everything work correctly. For example if you fiddle with the OS, it may be that all the threads don't get exactly the CPU core allocations they need where they need. Some threads are more related to each other than others. With the new EC modulators this is much much more sensitive with a deeper tree-like hierarchy. So far I have also tested it with Ubuntu Server 18.04 LTS and it's lowlatency kernel version. So if you encounter performance problems, you should test on a certified platform first to check. You know, it is painful to hear "I fiddled with things and now it doesn't work anymore".

 

HQPlayer Embedded improvements are on all 4.11 release packages.

 

23 hours ago, Superdad said:

Also, I know you use Ethernet pause-packets/flow-control with NAA.  But seems like you only do so for Gigabit connections.  Is that correct?  And are pause-packets/flow-control used with all NAA platforms? I know for Linux, but are Windows and macOS NAA the same?

 

That is way below OSI layer where NAA operates. So it is not related to NAA software as such, it is related to any transfer using full bandwidth like HTTP (including UPnP), FTP, etc. 802.3x flow control is handled by hardware, not software. It is needed for hardware that cannot cope with full bandwidth. For example i.MX6 SoC has 1 Gbps MAC, but can only do 400 Mbps through it's local bus. Software cannot cope with that because it is behind the slower link. So the hardware front-end needs to deal with it before it hits the slow 400 Mbps local bus link. On the second level there's also maximum number of packet interrupts kernel can handle per second on a certain CPU. If this is exceeded, interrupts are getting lost (interrupts coming in faster than interrupt handlers execute). This was issue with PCs as well when gigabit Ethernet was introduced, but not anymore. Ethernet 1500 byte MTU on a gigabit link generates quite high interrupt frequency if MAC generates interrupt for every Ethernet frame. This can be helped by using so called "Jumbo Frames" where MTU is larger than Ethernet default 1500 bytes. Can be even something around 9000 bytes (6 normal frames).

 

Also switches commonly use it. For example; if you have a gigabit 24-port switch connected to another switch through single gigabit link. In worst case all other 23 ports are trying to send data at full speed somewhere across to the other switch. That means 23 Gbps worth of traffic - so there's no way the switch can push all that through a single 1 Gbps link. So it can use flow control in round-robin manner between the ports to let traffic through in a controlled manner, instead of causing excessive packet loss while doing so. In lack of 802.3x support, many smart switches can alternatively generate back pressure by creating artificial collisions on the uplink, which is quite dirty way to deal with the same thing.

 

[Jud]

29 minutes ago, Miska said:

you wouldn't believe how much I spend time on testing and making everything work correctly

 

I would. 🙂

[lmitche]

12 minutes ago, Jud said:

 

I would. 🙂

Me too.

[Miska]

One note about EC modulators and stretching hardware to the limits. After struggling a day plus... If you play Tidal through Roon (Core doesn't need to be on the same computer) and you get jerky playback with dropouts. Try playing local content from Roon before concluding it is your CPU or settings! Or alternatively try Tidal through UPnP. If local content or UPnP works while Tidal/Qobuz through Roon doesn't it is not necessarily your CPU, settings or internet connection. Instead, please report here!

 

[Superdad]

1 hour ago, Miska said:

NAA functionality was updated along with the HQPlayer Embedded release on the HQPlayer OS image. I have not rebuilt all the networkaudiod packages for other OS. I think I versioned the new one as 3.5.7. If you want latest everything, just use the HQPlayer OS.

 

Thank you for your detailed explanations Jussi!

 

As far as NAA/networkaudiod, I am not seeing 3.5.7 on your web site--either as complete Linux image or as component. Only 3.5.6.  Are you distributing differently or just not ready to release 3.5.7?

 

Looking forward to comparing your newest HQP Embedded 4.11 Linux stick image to the AudioLinux/HQPe stick (with 4.10.2) I currently use.  When I compared previously your 4.10.2 image to my AL version, the AL version definitely had better SQ.  Don't ask me why, but it was apparent.

[Miska]

7 hours ago, Superdad said:

As far as NAA/networkaudiod, I am not seeing 3.5.7 on your web site--either as complete Linux image or as component. Only 3.5.6.  Are you distributing differently or just not ready to release 3.5.7?

 

Just haven't got time to release 3.5.7...

 

7 hours ago, Superdad said:

When I compared previously your 4.10.2 image to my AL version, the AL version definitely had better SQ.

 

The difference can be like stuttering / no stuttering, the one that doesn't stutter obviously has better SQ.

[Crom]

In my mission to rid myself of constantly regenerating fingerprints from trying to use the combination of HQPlayer and audiolinux, I too would like to compare the difference in SQ with one of Jussi's images. Can I just check which one I should be downloading...

 

From the jump in file sizes I'm assuming that the most recent builds probably have both the NAA and the HQPlayer packages installed...I seem to remember seeing that info in a post somewhere but can't find it now. So it seems like I should grab the 3561 image.

 

However, I use a Raspberry pi 2B as my end point (because it's the only device I can find that will allow me to remove USB from the audio chain and use I2S straight into the DAC. So...my question is which Pi build should I use, the latest one that is built for a pi2 (namely

naa-342-raspberrypi2? 

or...should I be using a difference build...also is it possible to update the software using a web interface or command line? I remember the last time I tried the NAA image there was very little possibility to customise etc and I couldn't get the right DAC driver to load in the pi config directory.

 

I have looked for answers to these basic questions but can't find them so any pointing in the right directio0n would be much appreciated. thanks, Crom

[luisma]

15 hours ago, Miska said:

One note about EC modulators and stretching hardware to the limits. After struggling a day plus... If you play Tidal through Roon (Core doesn't need to be on the same computer) and you get jerky playback with dropouts. Try playing local content from Roon before concluding it is your CPU or settings! Or alternatively try Tidal through UPnP. If local content or UPnP works while Tidal/Qobuz through Roon doesn't it is not necessarily your CPU, settings or internet connection. Instead, please report here!

 

Will report back, of course I do have noticed if you are streaming content 44.1 source will play fine but 96 content or higher might stutter 

[acatala]

17 hours ago, Miska said:

you wouldn't believe how much I spend time on testing and making everything work correctly.

 

I do belive you and I appreciate your effort very much. 

[Miska]

8 hours ago, Crom said:

In my mission to rid myself of constantly regenerating fingerprints from trying to use the combination of HQPlayer and audiolinux, I too would like to compare the difference in SQ with one of Jussi's images. Can I just check which one I should be downloading...

 

From the jump in file sizes I'm assuming that the most recent builds probably have both the NAA and the HQPlayer packages installed...I seem to remember seeing that info in a post somewhere but can't find it now. So it seems like I should grab the 3561 image.

 

You can find images and instructions for HQPlayer OS here:

www.signalyst.com/embedded-install.html

 

8 hours ago, Crom said:

However, I use a Raspberry pi 2B as my end point (because it's the only device I can find that will allow me to remove USB from the audio chain and use I2S straight into the DAC. So...my question is which Pi build should I use, the latest one that is built for a pi2 (namely

naa-342-raspberrypi2? 

 

That one is the latest build for RasPi2. I have not been building RasPi2 images anymore, but the old ones likely work for the onboard I2S still. The newer one is 64-bit RasPi3 image. For HifiBerry boards, I just swapped the old RasPi2's away and plugged the boards on newer RasPi3. Has been working fine. I assume it should also work for RasPi4, assuming they have not changed the connector pin assignments.

 

8 hours ago, Crom said:

or...should I be using a difference build...also is it possible to update the software using a web interface or command line? I remember the last time I tried the NAA image there was very little possibility to customise etc and I couldn't get the right DAC driver to load in the pi config directory.

 

No, both NAA images and the HQPlayer OS images are created to be "device firmware". So you just flash a new version when you want to update. And changing anything there is not very easy due to lack of any package management or such. But if you build something, you can just copy it in raw (with possible dependencies) and it may work.

 

[luisma]

On 7/12/2019 at 6:18 PM, Miska said:

Yes, I may be annoying with this stuff

Hi Jussi, just FYI and without being rhetoric here trust me. If this is related to the "yelled" statement.  I would not say you are annoying with this stuff, it is just it is designed to work on your platform, the "yelled" statement was more of a joke brought by another user. And we totally understand and we have never criticized anything as paid software users.

On 7/12/2019 at 6:18 PM, Miska said:

You know, it is painful to hear "I fiddled with things and now it doesn't work anymore".

We understand that fiddling with things may break things no doubt about it, sometimes we have to resort to multihomed etc. because of specific house configs etc. where we cannot have cable runs from one location to another in a simple easy fashion. If you recall I ran into some issues not because of fiddling but just updating, and yes the OS packages were updated too and maybe there lied the issue I don't know and if you recalled I never bothered you much with support as I know we are running on an "non officially supported config" and I get it.

 

Summarizing because I think it is important you know "my" (and possibly others) positions. 

 

1. HQPlayer it is by far the best software I (we) know capable of upsampling with a ton of different filters and modulators, PCM or DSD, discreet and multiple hardware architectures, multiple OS's, from the simplest to the more complex audio, performing "WHAT NO OTHER DAC OR ?SCALER DO" (and I'm not saying it is better than some DAC's, that would be an ignorant overstatement for which I'm not qualified) all this algorithm at a fraction of the cost of other devices in this HiFi world (this is just for the record  please I'm not trying to incline you to increase pricing). 

 

2. On top of that part by necessity, part by convenience you developed your own kernel and distribution for many different hardware platforms with optimized settings to get the best performance, we know, these settings perform as well or maybe better "than other paid versions of just software OS) and for that we are very grateful, to have for a reasonable price a great ecosystem of OS+software+options to allows to enjoy music even more. My point (and I presume yours as well) you are not only getting HQP you are also getting the optimized OS to run it as a non technical experience user just by copying an ISO image.

 

Now if you all others in this forum want to label me as a kiss a.. / brown nose etc. that is your prerogative.

 

Just what I really think

 

 

 

[Le Concombre Masqué]

4 hours ago, luisma said:

Hi Jussi, just FYI and without being rhetoric here trust me. If this is related to the "yelled" statement.  I would not say you are annoying with this stuff, it is just it is designed to work on your platform, the "yelled" statement was more of a joke brought by another user. And we totally understand and we have never criticized anything as paid software users.

We understand that fiddling with things may break things no doubt about it, sometimes we have to resort to multihomed etc. because of specific house configs etc. where we cannot have cable runs from one location to another in a simple easy fashion. If you recall I ran into some issues not because of fiddling but just updating, and yes the OS packages were updated too and maybe there lied the issue I don't know and if you recalled I never bothered you much with support as I know we are running on an "non officially supported config" and I get it.

 

Summarizing because I think it is important you know "my" (and possibly others) positions. 

 

1. HQPlayer it is by far the best software I (we) know capable of upsampling with a ton of different filters and modulators, PCM or DSD, discreet and multiple hardware architectures, multiple OS's, from the simplest to the more complex audio, performing "WHAT NO OTHER DAC OR ?SCALER DO" (and I'm not saying it is better than some DAC's, that would be an ignorant overstatement for which I'm not qualified) all this algorithm at a fraction of the cost of other devices in this HiFi world (this is just for the record  please I'm not trying to incline you to increase pricing). 

 

2. On top of that part by necessity, part by convenience you developed your own kernel and distribution for many different hardware platforms with optimized settings to get the best performance, we know, these settings perform as well or maybe better "than other paid versions of just software OS) and for that we are very grateful, to have for a reasonable price a great ecosystem of OS+software+options to allows to enjoy music even more. My point (and I presume yours as well) you are not only getting HQP you are also getting the optimized OS to run it as a non technical experience user just by copying an ISO image.

 

Now if you all others in this forum want to label me as a kiss a.. / brown nose etc. that is your prerogative.

 

Just what I really think

 

 

 

let's take my exemple : Jussi kindly helped me fiddling with Linux syntax for SMB and it was a loss of our times because I did not have the right hardware etc and in the end it's a much poorer option than using Audirvana or Roon for feeding tracks.

 

So now I perfectly understand that Jussi invites us to understand that he managed the complexity for us, that we have to adapt to his way, not to add further complexity

 

Why so ? I have taken Jussi's images, Balena etched them on 2 usb sticks connected to 2 machines and it's (almost) as simple as pushing 2 start buttons. With the right hardware, Embedded could be set up and enjoyed in minutes, almost Plug & Play while I spent days trying illiterate alternatives. When I have to directly plug a HDD to the Embedded machine and browse Embedded's Library page on my phone, and it's slightly cumbersome, I don't blame Jussi but myself because I have not managed yet to have full time a third machine with Audirvana to very conveniently feed Embedded

 

Bottom line : I rally the call to stick to what have been the most skilfully and patiently optimised.