HQ Player

[Gavin1977]

17 hours ago, Miska said:

 

Maybe one day it'll work under WSL. Last time I tried it was the UPnP component that failed. But Microsoft is actively developing WSL so there is hope. You would still need to have NAA somewhere, either at native Windows side on the same machine or somewhere else for audio input/output, but that is not a problem or at least lesser one.

 

Since Open Home is built off upnp, has full source code availability and control is there a need to wait?

 

I ask because I'm still using the trial version, if HQPlayer could recieve openhome/upnp then I don't see the reason for me to hold off on purchase anymore, as the need to use a suppporting linux based player such as gentoo, roon, euphony and so forth (and the extra layer of complexity they add) would no longer be required.  Game over.

[Miska]

1 hour ago, Gavin1977 said:

Since Open Home is built off upnp, has full source code availability and control is there a need to wait?

 

What source code are you talking about exactly? Under what kind of license terms? If you are talking about the Linn stuff, last time I checked years ago the source code wasn't really available under any open terms.

 

Next question would be suitability of the source code in first place for HQPlayer and the license terms. Then it would be possibly some months of work to integrate it to HQPlayer.

 

1 hour ago, Gavin1977 said:

as the need to use a suppporting linux based player such as gentoo, roon, euphony and so forth (and the extra layer of complexity they add) would no longer be required.

 

Why would you need Gentoo, Roon or Euphony? I don't have any Gentoo or Euphony here. I have Roon I use sometimes, but it is of course optional extra. You just boot HQPlayer OS firmware and you are done. You don't need to know or think about the OS itself.

 

[Miska]

3 hours ago, georgios said:

2. If I use a Firewire/USB interface for digital output and connect external DAC via AES connection, will HQPlayer still work as good as it should with such a configuration?

 

Yes, you just need to set correct number for "DAC Bits" to avoid truncation at the interface, because AES and S/PDIF are unidirectional and thus there's no way to detect resolution capabilities of the other side. In addition, some (many) such Firewire/USB interfaces lie their resolution being 32-bit, while AES and S/PDIF can only transfer 24-bit.

 

[georgios]

2 hours ago, Miska said:

 

Yes, you just need to set correct number for "DAC Bits" to avoid truncation at the interface, because AES and S/PDIF are unidirectional and thus there's no way to detect resolution capabilities of the other side. In addition, some (many) such Firewire/USB interfaces lie their resolution being 32-bit, while AES and S/PDIF can only transfer 24-bit.

 

Thanks, can you please enlighten me about clock sync strange behavior of HQPlayer?

[StreamFidelity]

Oct 6 2020

HQPlayer 4 Desktop 4.7.2 released. Component updates, some minor performance improvements and bug fixes. Note! Requires Nvidia display driver update for CUDA!

 

If you had problems with dropouts with versions 4.7.0 / 4.7.1, you will probably find the same with 4.7.2. Two cores run at a very high load.

 

 

 With 4.6.0 everything is fine. 😉 The utilization of the cores seems to be better distributed across all cores.

 

[Miska]

3 hours ago, georgios said:

Thanks, can you please enlighten me about clock sync strange behavior of HQPlayer?

 

I have no information about that one...

 

[Miska]

9 hours ago, Outlaw said:

Testing 4.6 works great.4.71 get drop outs with ASDM7EC.4.72 get drop outs now also with ASDM5EC.

 

That is interesting because there are no changes to poly-sinc filters or modulators between 4.7.1 and 4.7.2. Also compiler used to build both is exactly same version. From 4.6 to 4.7 compiler was updated to a newer version, but no code changes in those parts.

 

[Miska]

2 hours ago, StreamFidelity said:

Oct 6 2020

HQPlayer 4 Desktop 4.7.2 released. Component updates, some minor performance improvements and bug fixes. Note! Requires Nvidia display driver update for CUDA!

 

If you had problems with dropouts with versions 4.7.0 / 4.7.1, you will probably find the same with 4.7.2. Two cores run at a very high load.

 

 

 With 4.6.0 everything is fine. 😉 The utilization of the cores seems to be better distributed across all cores.

 

 

To me those loads look otherwise the same, except on 4.7+ the load on other cores is lower.

 

That should allow you to get more turbo boost on the loaded cores. 5 GHz without any problem.

 

 

[WilliamWykeham]

On 10/3/2020 at 1:01 PM, Miska said:

 

Which DAC is it?

 

 

Please check your USB cable, you could try replacing it with another standard, cheap USB HiSpeed certified one.

 

Such things can happen if there's a USB transfer error.

 

 

Sorry for delayed response.  I’m having trouble with both a Denafrips Terminator and a Toppimg D90.  Really confused why this would have stopped working suddenly. 

[WilliamWykeham]

On 10/3/2020 at 1:01 PM, Miska said:

 

Which DAC is it?

 

 

Please check your USB cable, you could try replacing it with another standard, cheap USB HiSpeed certified one.

 

Such things can happen if there's a USB transfer error.

 

 

I replaced the cable and am finding fewer incidences of this happening, from a few per day to one every other day. Thank you 

[Bones13]

I have a question. I understand the HQPlayer with Server to Endpoint -> DAC. Basically acting as the endpoint, receiving the music file, doing its magic, and outputting a stream, through USB, to the DAC.

 

I currently use a NUC using ROCK (Roon), on my network, to an Ethernet streamer device (Bricasti M12) I use the server to resample all my music to DSD128, which is max for the DSD specific DAC board in my device. There is no USB anywhere. (Well except the USB drive with my library, hanging off the NUC)

 

Would HQPlayer be of use in my system, specifically between a Roon server running on a Win10 based server (upgrade from the NUC) to “better” resample my mixed library of Redbook, HiRez, and DSD, files?

[Gavin1977]

23 hours ago, Miska said:

 

What source code are you talking about exactly? Under what kind of license terms? If you are talking about the Linn stuff, last time I checked years ago the source code wasn't really available under any open terms.

 

Next question would be suitability of the source code in first place for HQPlayer and the license terms. Then it would be possibly some months of work to integrate it to HQPlayer.

 

 

Why would you need Gentoo, Roon or Euphony? I don't have any Gentoo or Euphony here. I have Roon I use sometimes, but it is of course optional extra. You just boot HQPlayer OS firmware and you are done. You don't need to know or think about the OS itself.

 

http://openhome.org/pages/openhomelabs/

 

I just like the extra functionality provided by these software packages.

 

I will try boot of HQPlayer OS later - very few people have written about it.  Thanks

[Miska]

22 minutes ago, Gavin1977 said:

I will try boot of HQPlayer OS later - very few people have written about it.  Thanks

 

It is the HQPlayer Embedded, reference implementation of HQPlayer Embedded based device firmware.

 

[Miska]

6 hours ago, Bones13 said:

I have a question. I understand the HQPlayer with Server to Endpoint -> DAC. Basically acting as the endpoint, receiving the music file, doing its magic, and outputting a stream, through USB, to the DAC.

 

I currently use a NUC using ROCK (Roon), on my network, to an Ethernet streamer device (Bricasti M12) I use the server to resample all my music to DSD128, which is max for the DSD specific DAC board in my device. There is no USB anywhere. (Well except the USB drive with my library, hanging off the NUC)

 

Would HQPlayer be of use in my system, specifically between a Roon server running on a Win10 based server (upgrade from the NUC) to “better” resample my mixed library of Redbook, HiRez, and DSD, files?

 

Yes it would be useful for that purpose. But not so easy to integrate with your current system. As you cannot install it on ROCK, you would need to add another device to the networking running HQPlayer. Also since Bricasti M12 doesn't support HQPlayer endpoint protocol (NAA), you would need to replace the endpoint with something that does... So I would say not feasible unless Bricasti adds support for the HQPlayer NAA endpoint protocol.

 

[Gavin1977]

1 hour ago, Miska said:

 

It is the HQPlayer Embedded, reference implementation of HQPlayer Embedded based device firmware.

 

Just to say that it works a treat - the only thing I had to do was set it up as an open home renderer using bubbleupnp on my NAS... but I always have problems with devices not picking up upnp... hence the openhome investigations.

 

Any benefits running it from an HDD/SSD/M2 drive?

[Bones13]

2 hours ago, Miska said:

 

Yes it would be useful for that purpose. But not so easy to integrate with your current system. As you cannot install it on ROCK, you would need to add another device to the networking running HQPlayer. Also since Bricasti M12 doesn't support HQPlayer endpoint protocol (NAA), you would need to replace the endpoint with something that does... So I would say not feasible unless Bricasti adds support for the HQPlayer NAA endpoint protocol.

 

Thanks @Miska. That confirms my understanding.

 

I was wondering if the the HQPlayer “layer” could exist on a Windows10 server running the Roon server, then sending the file via Ethernet to the Bricasti. And this won’t work without an endpoint. Seemingly this would require an additional computer to be the endpoint, feeding the Bricasti via USB.

 

Trying to decide if upgrading from the ROCK is worthwhile. The i7 NUC6 runs ROCK, and resamples all files to DSD128 much smoother than the NAS I was using for a while. I will explore other avenues.

 

Really appreciate the immense amount of support you bring here.

[Miska]

On 10/8/2020 at 1:25 PM, Gavin1977 said:

Any benefits running it from an HDD/SSD/M2 drive?

 

Not really, you can dump it to SSD/M2 if necessary, but it is more extra complication without much benefit since the amount of storage access it does to the OS storage is minimal.

 

If the computer you are running it on has built-in SD-card reader (Intel NUC's being an example), you can also boot it up from a microSD or SD-card.

 

[Miska]

23 hours ago, Bones13 said:

I was wondering if the the HQPlayer “layer” could exist on a Windows10 server running the Roon server, then sending the file via Ethernet to the Bricasti. And this won’t work without an endpoint. Seemingly this would require an additional computer to be the endpoint, feeding the Bricasti via USB.

 

Yes, on regular Windows, macOS or Linux you can certainly do that, apart from the Bricasti endpoint support over network. If that computer is not far from the Bricasti, you could connect it directly via USB without extra computer and let HQPlayer send data to it over USB.

 

[WilliamWykeham]

On 10/3/2020 at 1:01 PM, Miska said:

 

Which DAC is it?

 

 

Please check your USB cable, you could try replacing it with another standard, cheap USB HiSpeed certified one.

 

Such things can happen if there's a USB transfer error.

 

 

@Miska and any others who might run into this - I think that I have isolated the issue - after verifying that DSD works correctly with three dacs and using HQP on another computer, I returned to my computer server running Windows Server 2019.  I tried to play a DSD file directly in HQP, and I couldn't get it start.  Then I stopped the Roon Server processes on my server - viola, HQP started sending DSD to my dac.  So I'm fairly confident that the issue is due to Roon Server not playing nice with HQP.  Actually, now I recall that I updated Roon a month or two ago, and that's approximately when the issue started.  So, I'll drop a line on a Roon forum and see if they have any advice.  

[jcn3]

7 minutes ago, WilliamWykeham said:

 

@Miska and any others who might run into this - I think that I have isolated the issue - after verifying that DSD works correctly with three dacs and using HQP on another computer, I returned to my computer server running Windows Server 2019.  I tried to play a DSD file directly in HQP, and I couldn't get it start.  Then I stopped the Roon Server processes on my server - viola, HQP started sending DSD to my dac.  So I'm fairly confident that the issue is due to Roon Server not playing nice with HQP.  Actually, now I recall that I updated Roon a month or two ago, and that's approximately when the issue started.  So, I'll drop a line on a Roon forum and see if they have any advice.  

 

i'm sure you did, but i'll ask anyway:  did you reconfigure roon to support the new location for hqp?  i've got roon and win10 running on the same computer (only upsampling to 756k) with no issues.

[Miska]

1 hour ago, WilliamWykeham said:

I tried to play a DSD file directly in HQP, and I couldn't get it start.  Then I stopped the Roon Server processes on my server - viola, HQP started sending DSD to my dac.  So I'm fairly confident that the issue is due to Roon Server not playing nice with HQP. 

 

Please check that you don't have your DAC enabled as a Roon zone. Otherwise you will have Roon and HQPlayer conflicting trying to control the same device.

 

[WilliamWykeham]

16 minutes ago, Miska said:

 

Please check that you don't have your DAC enabled as a Roon zone. Otherwise you will have Roon and HQPlayer conflicting trying to control the same device.

 

 

That was it - I had the dac enabled in Roon.  Problem fixed when I disabled.  Thanks!!

[Yviena]

@Miska interesting  the 4.7.x beta release you linked here managed to play EC7 DSD 256 smoothly  on 3700x even if it was using 2 threads on one CCD, and 2 threads on another CCD (first time playback on both CCD hasn't resulted in a stuttery mess), so there should have been a latency penalty incurred, if i do this first:

1: Playback a song with multicore ticked

2: stop song

3. Disable multicore

4. Start a song, stop it again

5:enable multicore

 

Also the cpu usage is now between 15.5-19.5% depending if I do the method above (without it it's around 19-20%), no idea why it works... the method above is consistently  lowering Hqplayer cpu usage between 2-3%, HQplayer is still using the exact same threads/cores as before.

[Miska]

2 hours ago, Yviena said:

@Miska interesting  the 4.7.x beta release you linked here managed to play EC7 DSD 256 smoothly  on 3700x even if it was using 2 threads on one CCD, and 2 threads on another CCD (first time playback on both CCD hasn't resulted in a stuttery mess), so there should have been a latency penalty incurred, if i do this first:

1: Playback a song with multicore ticked

2: stop song

3. Disable multicore

4. Start a song, stop it again

5:enable multicore

 

Also the cpu usage is now between 15.5-19.5% depending if I do the method above (without it it's around 19-20%), no idea why it works... the method above is consistently  lowering Hqplayer cpu usage between 2-3%, HQplayer is still using the exact same threads/cores as before.

 

4.7.2 release is pretty close to the beta.

 

Maybe it makes Windows move away some other threads from the most loaded cores. Or give higher clock boosts.

 

Have you tried on Linux? It could be more consistent...

 

[kohmelo]

I've been using 4.6. on Win10 machine without any issues on down clocked 9900K (all cores at 4,5GHz). All formats resampled to DSD256 with adaptive rate (Sinc-M/ASDM7EC).

 

Last weekend decided to update to 4.7.2 and started getting dropouts even when all cores set at 5GHz. As I couldn't find 4.6 version to download from anywhere, I went for Ubuntu 20.04. and no issues since (version 4.7.2). Cores are back to 4.5GHz and haven't come across a single dropout.