Jump to content
IGNORED

HQ Player


Recommended Posts

I hope this is an appropriate place to post this...

 

Like a number of people, I've found that I enjoy the sound of my 44KHz FLAC files when converted and played back as DSD128 so I've just loaded a demo copy of HQ Player and should be able to give it a listen shortly. Initially I've loaded it on an old PC with an Intel Atom 610 processor and will play output via a JL Sounds USBtoI2S card and a simple low pass filter 'dac'. The Atom PC will not have enough grunt to upsample on the fly so I've converted some files off line for now.

 

Going forward, I anticipate investing in a new PC spec'ed to be able to upsample and expect to run that remotely with the Signalyst NAA as that seems to considered to be the optimum configuration. That brings me to my question (and apologies if it's been answered elsewhere, I did look); I assume the Signalyst NAA puts it's output to a USB port for connection to a USB DAC? I know from my Beaglebone Black, that these sort of small ARM computers have enough power to playback DSD256 - I have a Beaglebone Black with Botic driver feeding a Buffalo IIIse and can playback DSD256 fine. Anyway, the beaglebone/botic combo connects to the network and outputs the PCM and DSD signals on its headers, negating the need for a USB card. Just wondering if anyone has done something similar with the Signalyst NAA package on something like a Beaglebone?

 

Cheers

 

Ray

Link to comment
I hope this is an appropriate place to post this...

 

Like a number of people, I've found that I enjoy the sound of my 44KHz FLAC files when converted and played back as DSD128 so I've just loaded a demo copy of HQ Player and should be able to give it a listen shortly. Initially I've loaded it on an old PC with an Intel Atom 610 processor and will play output via a JL Sounds USBtoI2S card and a simple low pass filter 'dac'. The Atom PC will not have enough grunt to upsample on the fly so I've converted some files off line for now.

 

Going forward, I anticipate investing in a new PC spec'ed to be able to upsample and expect to run that remotely with the Signalyst NAA as that seems to considered to be the optimum configuration. That brings me to my question (and apologies if it's been answered elsewhere, I did look); I assume the Signalyst NAA puts it's output to a USB port for connection to a USB DAC? I know from my Beaglebone Black, that these sort of small ARM computers have enough power to playback DSD256 - I have a Beaglebone Black with Botic driver feeding a Buffalo IIIse and can playback DSD256 fine. Anyway, the beaglebone/botic combo connects to the network and outputs the PCM and DSD signals on its headers, negating the need for a USB card. Just wondering if anyone has done something similar with the Signalyst NAA package on something like a Beaglebone?

 

I did a little more digging and found this post over on DIY Audio;

 

Building an open embedded audio applicance. - Page 79 - diyAudio

 

so it has been raised before but apparently not progressed. I concur with the sentiment of the poster and bringing together the HQPlayer NAA and the concept of the Botic distribution, removing the need to use USB, would move the NAA towards being a true network audio adaptor.

 

Any thoughts Miska?

 

Ray

Link to comment
There's no need to use USB at all, NAA itself is not related to USB in any way. Any audio device that has ALSA drivers is just fine, so you can as well use I2S outputs on some board, or for example on the CuBox-i the optical and HDMI outputs should work.

 

Many thanks for the response Miska. That gives me something to work from; firstly I need to understand a bit more about ALSA. Do you know of any examples of an implementation using I2S/DSD output from the headers of one of these small SOC boards that I could borrow from?

 

I'm assuming that in conventional UPnP/DLNA terms HQPlayer is a combined media server/renderer (with NAA being a physically remote component of the renderer)? Just trying to get my bearings.

 

Thanks

 

Ray

Link to comment
  • 3 months later...

Hello chaps. I'm a recent adopter of HQPlayer. I run it on a Xeon processor equipped Windows PC and I am achieving excellent results upsampling everything to DSD256 and then routing that to an NAA device that uses Debian on a low power Intel Atom computer. I'm deriving analogue through a simple low-pass filter.

 

Anyway, I currently use a conventional analogue volume control after the LP filter, which works fine but I find myself wondering about the volume control built into HQPlayer but I'm unclear whether it is intended to be used as a 'once off' general level setting or dynamically for tweaking volume during listening (as per a normal volume control)? Can anyone clarify or share their experiences?

 

I should say that I have followed the recommendations for max volume setting as specified in the manual. Noise shaping is currently DSD5 but I haven't really experimented with this yet.

 

Thanks

 

Ray

Link to comment
You can't play DSD256 on JLSounds whatever is your Os.

Maggio

 

I'm playing DSD256 through a JLSounds board.

 

Using AudioLinux and with HQP set for dual wire DSD256 was possible with DoP.

 

I'm now using an NAA setup with Debian Stretch core installed under the NAA package and that is playing native DSD256.

 

Ray

Link to comment
Either way, volume control is intended to be used. Especially for adjusting smaller amounts during listening.

 

I've only warned against using it as sole means of volume with high gain amps where accidentally applying full volume would have nasty results. For example if OS for some reason decides to play some of it's own sounds to wrong output at full level (like *bling* "you've got email"). Or if the the volume is too high due to some other accidental reason.

 

One way to use it is to first turn the volume control in HQPlayer to -3 dBFS and then adjust traditional analog volume control to highest expected and tolerable listening level. And then turn down the volume in HQPlayer to some currently desired level. This provides safety while commonly giving best possible signal to noise ratio in the chain.

 

Thanks Miska, I'll try it out. To follow up, is volume control exposed by the HQPlayer control API so that it can be controlled by packages like Muso or the forthcoming Roon hook up?

 

Ray

Link to comment
I'd expect this won't work correctly... Or does the board expose four channels? I don't have the new revision, so I cannot check myself.

 

It is possible I am mistaken but I can't check it myself either as I have rebuilt my NAA with Debian Stretch core; that definitely works with raw (i.e. no DoP) DSD256.

 

I've also just run a very quick trial and HQPlayer volume setting can be controlled with Muso as the front end. It's early in the morning so a serious listen will have to wait until later.

 

Ray

Link to comment

I only use HQPlayer for upsampling to DSD256 and output is fed, via an NAA device, to a Low Pass filter=based DSD 'converter' so no PCM capability.

 

I am currently 'driving' HQPlayer through Muso and tend not to interact with HQPlayer directly, however, if I forget to turn things on in the correct order and cause HQPlayer to error because it cannot find the expected NAA/decoder the output on the main screen defaults back to PCM and I have to access the HQPlayer main screen to reset to SDM (DSD) - something else to remember and inconvenient if you're using remote control.

 

Is it possible to configure HQPlayer for a DSD-output only scenario by disabling PCM or locking the output option to SDM (DSD)?

 

Ray

Link to comment

I only use HQPlayer for upsampling to DSD256 and output is fed, via an NAA device, to a Low Pass filter-based DSD 'converter' so no PCM capability.

 

I am currently 'driving' HQPlayer through Muso and tend not to interact with HQPlayer directly, however, if I forget to turn things on in the correct order and cause HQPlayer to error because it cannot find the expected NAA/decoder the output on the main screen defaults back to PCM and I have to access the HQPlayer main screen to reset to SDM (DSD) - something else to remember and inconvenient if you're using remote control.

 

Is it possible to configure HQPlayer for a DSD-output only scenario by disabling PCM or locking the output option to SDM (DSD)?

 

Ray

Link to comment
HQPlayer recognizes the situation where ASIO driver reports device to support only DSD and no PCM at all. But if the driver claims PCM support, then in some cases the output mode may get reverted since PCM is the default.

 

Thanks Miska. I use a JLSounds USB board, plugged into a Debian Stretch-based NAA so it will have PCM capability, though I never use it. It would be nice to be able to set DSD as the default?

 

Or perhaps I could do something in ALSA...

Link to comment
  • 1 month later...
Ubuntu Studio 15.10 works. I'm able to play non-DoP DSD stream with JLsounds USB card, I tried with DSD256 upsampling as well and I was able to see DSD256 on DAC display but then my poor i5 can't really stream the file to life.

 

Nice test. I will try to do the same with Linux Mint 17.2

 

Have a nice day. Massimiliano

 

I thought it might be of interest that I have an NAA working with non-DOP DSD256 (via JLSounds USB board) using Debian Stretch core (no GUI or other extras, just what is required to run NAA). For the NAA hardware I'm using an Intel NUC E3815; Debian Stretch core runs on the onboard 4Gb eMMC (no SSD or HDD required). If anyone is interested the documentation here might be of use;

 

The Best DAC is no DAC - Page 61 - diyAudio

 

though I am conscious that it needs some small updates. Be gentle too, I am no Linux expert.

 

Just to complete the picture, for my main HQPlayer computer I am using a 3-4yr old 3.4GHz quad-core Xeon equipped PC running Windows 10. With Poly-sync-2s and DSD7+257fs at 12288000bit rate CPU loading is around 35%. The main PC has two network cards, one connects to the normal home network (where my FLAC library is hosted on a NAS) and the second connects to a dedicated NAA network, based on a gigabit router/switch (so I can connect several NAA devices in different rooms).

Link to comment
In my Jplay 2 pc setup the control PC has 2 network ports. The first port is used to connect to my router so it can access the NAS where all my music is stored. The second port is used to directly connect the control PC and audio PC. The audio PC does not connect to my network or internet at all.

 

If I was to use the NAA, would this setup be correct?

 

That's essentially what I have; it works well.

 

http://www.computeraudiophile.com/f11-software/hq-player-20293/index178.html#post500496

 

Ray

Link to comment
  • 4 weeks later...

I've just built a 'no-DAC' decoder project; just a basic low-pass filter based build using a JLSounds USB board. It's my second such project but rather more refined than the first 'prototype'.

 

Unlike the 'prototype' which had an Alps potentiometer for volume control, the new build has no analogue volume control as I'm planning to use the HQPlayer volume control. One of the first things I noticed with playback on the new project was a mushy, white noise background sound. I reinstalled my 'prototype' and disabled the HQPlayer volume control and the mush disappeared. Setting the Alps pot to max and using the HQPlayer volume control (DSD Direct ticked) the mush returns? So on two different playback devices I get the background mush. The mush is only present with HQP volume control enabled and during playback and doesn't seem to very in level (it gets masked at louder volumes and is most noticeable during quiet passages).

 

For completeness, I am upsampling 16bit 44.1KHz PCM files (CD rips) to DSD256 (1228800) using poly-sinc-2s and DSD256+fs. Upsampling is on a workstation running Win10 with output streamed to an NAA device over a dedicated Ethernet link. HQP version is 3.12.0 (I have just updated from 3.11). Thoughts?

 

Changing the subject a little, I am using a muting relay, triggered by the Codec header pin on the JLSounds USB board, to try and eliminate pops and clicks. On my 'prototype' project with HQP 3.11, I wasn't getting any extraneous noises. Now, with both of my playback projects and HQP 3.12.0, I am getting loud pops whenever I use the 'Play' or 'Stop' functions in HQP - the mute circuit is working, I can hear it clicking with no power amps turned on and have checked the voltages across the relay coil, but it seems to be reacting too slowly as if the trigger isn't reading far enough ahead? Any thoughts on how to mitigate this?

 

Thanks

 

Ray

Link to comment
Great stuff Ray! HQPlayer looks to talk to the DAC chip normally.

I wonder what happens now that there is no DAC chip at all.

 

What Volume Settings (max and min values) did you use and what do you specify for "DAC Bits"?

 

HQP is 'talking' to the JLSounds I2SoverUSB board.

 

I tried a variety of volume settings but didn't note specific values as the result was consistent until I returned to DSD Direct mode.

 

'DAC Bits' is set to 'default'

 

Ray

Link to comment
I've just built a 'no-DAC' decoder project; just a basic low-pass filter based build using a JLSounds USB board. It's my second such project but rather more refined than the first 'prototype'.

 

Unlike the 'prototype' which had an Alps potentiometer for volume control, the new build has no analogue volume control as I'm planning to use the HQPlayer volume control. One of the first things I noticed with playback on the new project was a mushy, white noise background sound. I reinstalled my 'prototype' and disabled the HQPlayer volume control and the mush disappeared. Setting the Alps pot to max and using the HQPlayer volume control (DSD Direct ticked) the mush returns? So on two different playback devices I get the background mush. The mush is only present with HQP volume control enabled and during playback and doesn't seem to very in level (it gets masked at louder volumes and is most noticeable during quiet passages).

 

For completeness, I am upsampling 16bit 44.1KHz PCM files (CD rips) to DSD256 (1228800) using poly-sinc-2s and DSD256+fs. Upsampling is on a workstation running Win10 with output streamed to an NAA device over a dedicated Ethernet link. HQP version is 3.12.0 (I have just updated from 3.11). Thoughts?

 

Changing the subject a little, I am using a muting relay, triggered by the Codec header pin on the JLSounds USB board, to try and eliminate pops and clicks. On my 'prototype' project with HQP 3.11, I wasn't getting any extraneous noises. Now, with both of my playback projects and HQP 3.12.0, I am getting loud pops whenever I use the 'Play' or 'Stop' functions in HQP - the mute circuit is working, I can hear it clicking with no power amps turned on and have checked the voltages across the relay coil, but it seems to be reacting too slowly as if the trigger isn't reading far enough ahead? Any thoughts on how to mitigate this?

 

Thanks

 

Ray

 

Last evening I reverted back to HQP 3.10 but still got the white noise mush in the background when using the HQP volume control. I also experimented with different settings for the upsampling but those I tried made no difference. In Direct DSD mode the noise is not present.

 

Ray

Link to comment
I've a similar setup but a different issue ...

 

JLSounds I2SoverUSB board with AK4490 DAC board. With DAC with DSD Direct mode, if I start play a DSD file, playout bar move normally but no sound exit ... In order to have sound, I need to manually operate display buttons and set DSD mode with volume and then back to Direct.

 

This setup works correctly until disk ends. Then If I start a new disk, I need to do the procedure again.

 

Have you noticed any similar issue ?

 

Have a nice day. Massimiliano

 

No, I don't experience anything like you describe, functionally everything works as I expect.

 

Cheers

 

Ray

Link to comment

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