Jump to content
IGNORED

HQ Player


freesteve
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

 

39594908cw.png

 

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

 

39594909qi.png

Grigg Audio Solutions Owner

StreamFidelitys Setup

Sonus Faber Amati Futura | T + A M10 | T + A SDV 3100 HV | fis Audio PC | HFX RipNAS Solid V4 | GigaWatt PC4-EVO + | Afterdark Buffalo Switch | Solidsteel HJ-3 / HY-A

Link to comment
Share on other sites

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.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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.

 

39594908cw.png

 

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

 

39594909qi.png

 

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.

 

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

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?

[Home Digital] Bricasti M12 > DIY M2x Monoblocks > Daedalus Audio Muse Studio Speakers

[Home Analog] Technics SL-1200G > Boulder 508 (Zu DL-103/Hana ML/Denon DL-301 II)

[Office] Laptop > Kitsune R2R lvl3 > Violectric V281 > Focal Utopia Headphones (balanced)

[beach/Travel] Laptop > DragonFly Red > Ether Headphones

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

[Home Digital] Bricasti M12 > DIY M2x Monoblocks > Daedalus Audio Muse Studio Speakers

[Home Analog] Technics SL-1200G > Boulder 508 (Zu DL-103/Hana ML/Denon DL-301 II)

[Office] Laptop > Kitsune R2R lvl3 > Violectric V281 > Focal Utopia Headphones (balanced)

[beach/Travel] Laptop > DragonFly Red > Ether Headphones

Link to comment
Share on other sites

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.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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.

sources:  intel nuc8i7 (audiolinux, roon core) (server) | simaudio moon mind 2 (renderer)
headphone rig:  chord qutest > bryston bha-1 > audeze lcd-3
main rig:  chord dave > parasound jc5 > kef reference 1
Link to comment
Share on other sites

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.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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...

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
 Share



×
×
  • Create New...