HQ Player

[elan120]

Hope this is the right place to inquire some help on the setup.

 

Over the weekend I changed my PC from an older laptop with Windows 8.1 to a more powerful desktop that is running Windows 10, in the process of transferring HQPlayer to the new PC, it will now only play 384K PCM output to my DDC (Singxer SU-1) and then my DAC (Holo Spring), and I also noticed the Auto Rate Family can no longer be selected since any other output sample rate will not be accepted by the DDC/DAC.  Moving back to my old laptop using the same version 3.17 resulted in the same condition unless I revert back to version 3.16. so I wonder if there are things I didn't setup correctly and hope to get some pointers with the information provided.

[elan120]

Just now, scan80269 said:

Is the new Win10 PC running the same Holo Audio USB driver as the older Win8.1 laptop?  I believe v3.40.0 is the latest driver version for Holo Audio Spring DAC.

 

 

 

 

No, the laptop is using the Windows 7/8 version 3.40 driver, and the new Win10PC is installed with Windows 10 version 3.40 driver.  Both were downloaded from Kitsune's website.  I did try installing Windows 7/8 version 3.40 driver just to see if that makes any difference since I ran out of the idea on what to do, and that didn't work as expected on Windows 10.

[elan120]

I did try Foobar2000 last night, but not sure what I have missed, for some reason, Foobar isn't seeing the Holo driver to be selected.  I will try again since I have done another install to make sure it is installed correctly, so hopefully the driver will be available this time.

 

I also have tried connecting USB output directly to Spring DAC (bypassing SU-1), it did play 384K, but that was in early stage of troubleshooting, and I have not try testing with other output frequencies.  I will try this later this afternoon when I get home.  Thank you for the idea.

[elan120]

That is good to know, although I did do this last night, but will try it again just in case.

[elan120]

6 minutes ago, Miska said:

I would assume Singxer to use different driver than the Holo Spring DAC standalone, because IIRC they use different USB ID's.

My understanding is they only have one driver if using Singxer SU-1 and Spring DAC together as a set, due to the signed driver is for one unit only, and it should only apply to SU-1 when installing the driver.  I will check it in a few hours to find out if the same driver will work with DAC along.

[elan120]

Just now, tboooe said:

In order to use the Spring by itself after removing the SU-1, you have to uninstall and reinstall the driver.  I was told that at installation, the driver is set for a specific hw.  I had this issue a while ago when I sent out my SU-1 to get modded and I couldnt just plug my pc into the Spring and make it work.

Good point, I will keep this in mind when I check the direct connection method in a short while.  I did upgrade SU-1 firmware to version 2.20 when it was first introduced few month ago, and was told also new driver can only be assigned to one hardware, and with the combo SU-1 and Spring DAC, it will be the SU-1, and it make sense if I bypass SU-1, I will need to re-install the driver to point it to the Spring.

[elan120]

3 minutes ago, scan80269 said:

I just hot-bypassed my SU-1, i.e. unplugged the USB cable from the SU-1, plugged it into the Spring DAC USB port, switched Spring input from I2S to USB, and got 352.8K PCM and DSD512 to play without incident.  The only thing I did was to re-launch HQPlayer 3.17 after changing the HW.

 

The INF file of the Holo Audio Spring USB driver shows the following:

 

[_Models.ntamd64]
"XMOS USB Audio Interface"=_Install, USB\VID_20B1&PID_3036    ; this ID belongs to Holo Audio Spring DAC
"XMOS USB Audio Interface"=_Install, USB\VID_20B1&PID_3086    ; this ID belongs to Singxer SU-1

 

These ID entries explain why the Holo Audio Spring USB driver can be used with the SU-1.  The comments above are mine.

 

Thank you for the testing and confirmation.  I will try this a little later to see if it will play similar like yours...hopefully...

 

If nothing else will work, I plan on start everything from scratch and see if a new clean install of everything will yield better result.

[elan120]

I hope for the best as well...it was not the idea having a more powerful PC to just run one output frequency at 384K, where my old laptop can do all output frequencies like it should.  Very puzzle what I have missed while doing the installations.

[elan120]

9 minutes ago, Miska said:

Only one thing comes to my mind. I think Win10 now finally has UAC2 driver. Check that it is not that driver claiming the device. You can use Device Manager to check which driver is loaded for the USB device. If the driver vendor is Microsoft, then you know where the problem is...

 

I've had some driver problems on Windows 10 Creator's Update. Sometimes for example devices need to be powered up while making Windows cold boot. Otherwise sometimes driver wasn't loaded properly later when the device was powered up. On these issues, disabling Quick Boot from Windows -> Control Panel -> Power Options may help, because then Windows makes real cold boot, and not just loading of pre-stored RAM image.

 

I didn't check this, and certainly is an area I will explore later to make sure.  Thank you for point this out, and will report back my findings.

[elan120]

2 minutes ago, scan80269 said:

Yes, to get a true cold boot with Win10 (& Win8/8.1), the "Turn on fast startup" checkbox (under Control Panel -> Hardware and Sound -> Power Options -> System Settings) needs to be unchecked.  This "feature" is supposed to speed up OS boots, but it actually replaces an OS full shutdown with OS hibernation (after terminating apps).  On the next system turn on, OS will be reloaded from hibernate file instead of booting from scratch.  If you have a yellow bang in Device Manager for whatever reason, after this fake OS shutdown and subsequent system power up, the yellow bang will still be there!  Restarting OS is not affected by this fake shutdown, but the HW is not power cycled by an OS restart.

 

Whenever I do a fresh installation of Win10, I always disable "Turn on fast startup (recommended)" manually.  Since most of my PCs boot from SSDs, disabling this feature will help reduce SSD wear as well.  This fake shutdown feature can also be disabled indirectly by removing the hibernate file: powercfg -h off (in elevated command prompt).

 

 

Great, another area I didn't check, and this will also help eliminating possible root causes.  Thank you!

[elan120]

After trying out the suggestions from @scan80269 and @Miska, I did the following

1. Deselect Fast startup feature follow with a cold boot - issue remain

2. Uninstall and then reinstall Holo Spring driver version 3.40 - issue remain

3. Uninstall and then reinstall HQPlayer 3.17 follow with cold boot - issue remain

4. Uninstall HQPlayer 3.17 and install HQPlayer 3.16.3 follow with cold boot - issue remain (this was an attempt due to lack of things to try)

5. Bypass SU-1, connect USB output from PC directly to Spring DAC input - can play both 352.8K 384K frequencies

6. Reconnect SU-1 back in front of Spring DAC - issue came back

 

Does this mean somehow SU-1 isn't running Holo Spring driver correctly?

 

According to Device Manager status, Holo Spring driver appears to be running correctly - see below

 

At this point, I am running out of ideas again, and could use some more help and ideas to continue the troubleshooting.

[elan120]

Some more updates...

 

1. Uninstalled HQPlayer 3.16.3 and reinstalled HQPlayer 3.17 - issue remain

2. Tested Foobar2000 by using Holo Spring driver, it will play PCM (44.1K) with direct connection to Spring DAC, but will not work when connecting SU-1 in between.

3. Bypass SU-1 again, connect USB out from PC directly to Spring DAC USB input, can play both 352.8K and 384K PCM inputs BUT cannot play DSD.  HQPlayer will crash if any of DSD rates are used.

 

Really not sure if the problem is with HQPlayer or Holo Spring driver, or somewhere else.

 

Any help is greatly appreciated.

[elan120]

3 minutes ago, Altabay said:

 

I know this sounds silly... but did you try rebooting everything?  Computer, SU-1, and especially the Spring DAC.  It would be nice if you can test another DAC or another SU-1.  How about using AES or coax to connect SU-1 to the DAC?  Can you play the other rates then?

Yes, I did try rebooting everything.  When installing the Holo Spring driver, I specific left the Spring DAC power off to make sure only SU-1 will be the hardware for the driver.  I also have tried coax output from SU-1 to Spring DAC with the same issue - only 384K can be played.  It would be nice to have another SU-1 to try but I am very positive DAC isn't the issue since most of the later test were done with DAC power off anyway.  Appreciate your input, and at this point, nothing sounds silly at all.

[elan120]

This is what I am currently doing, but it was working fine just the other day, but now even the original equipment/setup show exactly the same issue...could be SU-1 after all...will try few more test to confirm.

[elan120]

3 hours ago, Miska said:

If the DAC works fine PCM & DSD with direct connection without SU-1, then it means both the driver and DAC are fine. That leaves only the SU-1 as possible issue (or the I2S link between the two).

 

I have Spring L2, but I use it only with direct USB connection...

Hi Miska,

 

That is the confusing part that the direct connection play PCM fine with different frequencies, but cannot play DSD.  HQPlayer will crash regardless of rate used.  I started with 512, reduced to 256, and then 64, every time when DSD is played, it will have the same error message that HQPlayer encountered unrecoverable error, looking for solution...and then close the application.  This issue adds more puzzle to define the true root cause...

[elan120]

Checked the Spring XMOS USB driver volume control, it is set at max (0db).

 

Changed I2S cable, but DSD still can't be played with direct connection to Spring DAC.  The connection point seem to be working fine but HQPlayer still crash though.

[elan120]

Just now, pkane2001 said:

 

Be careful playing with Spring driver volume controls. I had the uncontrollable urge to adjust something, and so moved the SPDIF volume control in the driver settings to its minimum value to see what it'll do. The DAC went crazy and started feeding high pitched noise at 0dB into my amps that blew out the right tweeter! Thankfully I was able to repair it (just a melted lead wire).

Thank you, and this is good knowledge, I only checked the settings and didn't think I need to do anything there, so left the settings alone, now there is more reason not to bother with them...

 

My troubleshooting journey continues...to this point, the first thing I wish to figure out would be why HQPlayer would crash if DSD is played even with direct PC USB to Spring DAC USB connection.  If this problem is solved, culprit likely can be defined as SU-1, but with both DSD not able to play without SU-1 connected and only 48K family frequencies can be played with SU-1 connected, it is hard to pin point to just one possible root cause...

[elan120]

HQPlayer crash on both 3.16.3 and 3.17 on Win 8.1 trying to play DSD native.

 

I have neither checked DoP nor OS/NOS operations, but certainly be a good test later this afternoon when I get home from work.  Maybe DoP will work since I can play all PCM frequencies.

 

DAC seem to be in proper working order and I have left power off for more than an hour few times during troubleshooting, but won't hurt to try again just to be sure.  Will report back when I get more test results later.

[elan120]

I will do a screen shot of HQP settings when I get home this afternoon.

 

I have not tried DSD with foobar, and have not figure out why I can't get ROON to play output to Spring DAC using Holo Spring driver at the moment as time have been solely spent on troubleshooting HQP...

[elan120]

6 minutes ago, Miska said:

 

Are you sure you haven't accidentally enabled "AltDSD" setting?

Ahhh...no, I am not sure about this, and will check on this first thing when I get home later this afternoon.  Hopefully this will solved the DSD playing issue...thank you for point this out.

[elan120]

6 hours ago, Miska said:

 

Are you sure you haven't accidentally enabled "AltDSD" setting?

Things are looking up slightly, and I want to express my gratitude to @Miska, @scan80269, @Altabay, @tboooe, and @pkane2001 for providing valuable suggestion and experience in the past few days.  Meanwhile, I also want to thank everyone else patiently let me have this space to work this issue.

 

Just checked the AltDSD setting with direct connection from PC to Spring DAC without SU-1 in between, and is surprised that I did somehow enabled this selection.  Unchecked the box get all DSD playback working all the way up to 512, and this continue to work after moving everything back to the new PC with direct connection running HQP version 3.17. 

 

The culprit likely now narrow down to SU-1, and this may not be a right thread to continue the troubleshooting since HQP setup related issue is now lifted.

[elan120]

1 hour ago, scan80269 said:

That's a good bit of troubleshooting!

 

I still have a hunch your issue is related to the I2S link between SU-1 and Spring DAC.  One thing you can try is to temporarily replace the I2S link with S/PDIF or AES (using the appropriate cable of course) to see if the Spring DAC can play PCM up to 192K and DSD64 DoP.  If these work OK then it would suggest the I2S connection from SU-1 to Spring DAC has been somehow compromised.

 

I mentioned the very loose fit between my Spring DAC I2S-HDMI receptacle and the cable, and I suspect it's rather easy for the cable to have over-strained that Spring DAC I2S-HDMI receptacle to the point that some of the signals are not making electrical contact at the connector matings.  If the Spring DAC I2S-HDMI receptacle has been mechanically compromised then even another HDMI cable may not help.  My gut feel is that this is more likely to be a mechanical issue than an electrical issue.  Just a thought.

 

It is still inconclusive at this point.  I tried using coax1 out from SU-1 to Spring DAC coax1 in, per your suggestion, and that didn't make any difference.  I then again move back to I2S connection, and it will play 384K all the way to Spring DAC, but when HQP playing 352.8K, SU-1 does show signal came in (middle blue LED on), but no signal out to Spring DAC (LED showing ---- ---- ---- ---- ----).

 

Without knowing more about SU-1 circuit, it is getting a bit more challenging to continue.  I did measure SU-1 22.5792MHz oscillator pin-1 and pin-3 output, when I play Foobar at 44.1K and HQP at 352.8K output, pin-1 will go from low to high (0VDC to 3.3VDC), and pin-3 will have output (1.6x VDC), and same result also applied to 24.576MHz oscillator when playing the 48K output families.  This shows that incoming portion of SU-1 is working correctly, but I am a bit lost where the signal goes after that to continue measure and trace the signal, especially why 44.1K and 352.8K output signal isn't going to the I2S output when the output from oscillator (pin-3) is correct.

[elan120]

7 minutes ago, scan80269 said:

As of yesterday I have fixed @elan120's SU-1.  It had an issue of the 22.5792MHz reference clock being cut off from the Xilinx FPGA.  A small resistor in series with the clock trace sat crooked on the circuit board with one pad making intermittent contact which eventually became an open circuit hard failure.  After resoldering this resistor into position this SUI-1 unit has regained full functionality in playing all content with 44.1K family sample rate as well as DSD up to DSD512.

 

Special thanks to @scan80269 for finding and repaired this issue.  The crooked sitting resistor came originally from the factory that has been working since I started using this SU-1 several months ago, but @scan80269 was able to spot the problem quickly and get the problem resolved.

 

I feel very blessed to have this kind of help and assistance!  My SU-1 is now playing great music using HQPlayer upsampled to DSD512 since received it back from  @scan80269  yesterday.  

[elan120]

3 minutes ago, Outlaw said:

Since the latest update of HQPlayer and Windows weird things happening in task manager.When I open task manager showing cpu load of 28% but HQPlayer only showing around 6%,but no other cpu usages.The load before was around 28 % but HQPlayer was showing CPU usage of around 26% ?

That does sound strange.  I am on version 3.25, but not seeing the same issue you described, I have 34% usage on CPU and HQPlayer has around 32.5% usage.  Maybe Miska has some insight?

[elan120]

2 hours ago, eternaloptimist said:

Well, the ASUS DUAL RTX 2080 arrived in the post today and is now installed. Wow, this card is a beast!

I can upsample to DSD512 (to T+A DAC 8 DSD via NAA) with poly-sinc-xtr, poly-sinc-xtr-mp without a problem.  The CUDA offload is impressive. Task manager tells me the CPU (i6700K) is sitting stable at around 35%, the graphics card at 60 - 70%. With less intensive filter, the GPU usage sits at around 5 - 7%.

Am having a lot of fun experimenting! The poly-sinc-xtr-mp is remarkable - very dynamic!

 

Very good to know this GPU can elevate performance this much.  Could you try "Closed-form-16M" at 512?  This seems to be the real stress test of all the filters.