HQ Player

[louisxiawei]

I'm happy that 3.16.0 combined the sq of 3.15.0 with faster filter initialization of 3.15.1.

 

Hey Bogi,

 

Although I find 3.16 is much better than 3.15.1 in terms of SQ. Less harshness. I still feel the 3.15 has more natural and analog sounding.

 

The explanation of Multicore DSP 3 levels is provided in the manual.

 

Blank~None.

Grey box ~ Auto detection

Tick ~ Multicore DSP enabled.

 

However, I do feel the Multicore DSP difference. Without ticking multicore DSP, DSD512 cannot be played because of serious stutter. (my CPU is quite weak, i7 3770). Fortunately, I have my GTX780 to ease my CPU load.

 

 

On the manual, if the cuda offload is enabled, the multicore dsp is recommended to be swithced on.

[louisxiawei]

A somewhat theoretical question, and one that is likely quite dac-dependent, but will ask anyway:

* is it better to strive to get to the dac's max sample rate even if it involves a lighter weight filter (say, poly-sinc-mp-2s) than doing less-than-maximum sample rate with heavier filters (say poly-sinc-mp)? This question also has a slight variation: is sample rate family as important (do 48k-based stuff to 384k even if it requires lighter filters than instead doing 352k for everything)? I know the answer should include listening impressions, but asking anyway, given several factors that are not easily changed on the spot (the biggest one being compute horsepower).

 

Hey Ted,

 

I did what you suggest on my exasound e12 long ago. In my case, DSD256+FS with poly-sinc-2s sounds better than DSD256 with poly-sinc, yet the former one consumes less cpu.

 

 

DSD256+fs with lighter filter (poly-sinc-2s) sounds much more natural, relaxing, vivid than lower sampling rate at heavier filtering. After that comparison, I pulled the trigger on T+A DAC8 DSD, because I have high expectation on DSD512 based on that experience, and the same thing comes to T+A DAC as well.

 

So in my opinion, I do feel the sampling rate comes before the filter's heaviness in terms of SQ.

[bogi]

Hey Bogi,

 

Although I find 3.16 is much better than 3.15.1 in terms of SQ. Less harshness. I still feel the 3.15 has more natural and analog sounding.

 

IMO 3.15 brings a bit darker sound, on my system especially when [x] PipelineSDM is ticked. In louder and brighter passages it may sound better. From this point of view 3.15 may be safer option. On some more quiet passages with less instruments I may find more detail with 3.16.

 

I can tune sound from analytical to very relaxed in XMOS ASIO Control Panel.

 

[Miska]

On the manual, if the cuda offload is enabled, the multicore dsp is recommended to be swithced on.

 

Either multicore "enabled" or "auto". CUDA affects the decision making for "auto". The "enabled" is like "all on" and "disabled" is "all off" and then auto has some more variablity based on number of CPU cores and whether CUDA is enabled or not and some other settings. So most of the time "auto" should give most optimal results.

[louisxiawei]

Either multicore "enabled" or "auto". CUDA affects the decision making for "auto". The "enabled" is like "all on" and "disabled" is "all off" and then auto has some more variablity based on number of CPU cores and whether CUDA is enabled or not and some other settings. So most of the time "auto" should give most optimal results.

 

Thanks, Miska.

 

Could you please make any comment for the SQ change in recently released version? I have a feeling that the SQ change might due to the change you made on multi-core CPU setting in 3.16 or SDM pipeline setting in 3.15.1?

 

Does it make any SQ difference on your PC setup from your experience?

[bogi]

Miska, thanks for the explanation of auto setting.

 

I found that both slider and seconds in the time counter may flow unevenly.

Maybe it has some relation to more pulsing processor utilization since 3.15.

[louisxiawei]

I can tune sound from analytical to very relaxed in XMOS ASIO Control Panel.

 

Thanks bogi, I have to say the description of your listening experience is on spot.

 

Shame that my dac uses amanero USB interface and cannot tune the sound in XMOS' way.

 

I tried to set different buffer time in HQplayer but it doesn't help too much.

 

Looks like it is more or less a SQ tuning issue now.

 

Thanks again.

[Miska]

I found these remarks you made last year and I was wondering what you meant by "disabling" the Mojo volume control.

 

Do you mean setting it to full volume or invoking the "line out" level preset?

 

I mean the line out level preset. IIRC, holding the two volume buttons down while powering up the DAC.

[ted_b]

IMO 3.15 brings a bit darker sound, on my system especially when [x] PipelineSDM is ticked. In louder and brighter passages it may sound better. From this point of view 3.15 may be safer option. On some more quiet passages with less instruments I may find more detail with 3.16.

 

I can tune sound from analytical to very relaxed in XMOS ASIO Control Panel.

 

[ATTACH=CONFIG]34119[/ATTACH] [ATTACH=CONFIG]34120[/ATTACH]

 

Yes, I find the 3.15 and 3.16 to be closer in sq and not the brittle sound of 3.15.1, but there are the differences you so eloquently describe. I am wondering if the various AO settings (sonic signatures) will help here. Yikes, so many variables, so little time.

[ted_b]

Jussi, I realize it's getting very late, so if in the am you have the time to gander at my questions on post #8380

http://www.computeraudiophile.com/f11-software/hq-player-20293/index336.html#post646713

[Lionelh2]

I mean the line out level preset. IIRC, holding the two volume buttons down while powering up the DAC.

 

Thanks. Just tried it, Sounds better to me as well

 

 

Sent from my iPhone using Computer Audiophile

[Solstice380]

Miska, thanks for the explanation of auto setting.

 

I found that both slider and seconds in the time counter may flow unevenly.

Maybe it has some relation to more pulsing processor utilization since 3.15.

 

I have had the uneven time counter since at least 3.14 something. It is what led me to correlate it to the sinusoidal CPU usage in the the screenshot I posted. I have played with buffer settings both in HQP and in an ASIO control panel (McIntosh) with no consistent change in the timer behavior. Some times it is relatively stable and others it runs fast for up to 4-5 seconds and then waits. Network activity correlates with this also. Using a Lampi with Amanero USB it still occurs, no control panel for this ASIO.

 

I don't remember this ever happening back when I used a direct PC-DAC connection so I wondered if it was NAA network related. That was also many HQP versions back. I also wonder if it may be when you have a lot of headroom in the CPU/GPU and the processing happens quickly enough that there are slack periods? Using poly-sinc-shrt-mp and ADSDM512+ the CPU runs ~21% for 44.1>DSD512 and ~28% for DSD64>DSD512. As us Z170 mono, i7 6700K, GTX970, 16GB G. Skill DDR4 2400 15 latency. Win 10 not slimmed very much to ~50 processes.

 

BTW, 3.16 sounds really good at DSD512 through a Lampi chipless DAC.

[Miska]

* is it better to strive to get to the dac's max sample rate even if it involves a lighter weight filter (say, poly-sinc-mp-2s) than doing less-than-maximum sample rate with heavier filters (say poly-sinc-mp)?

 

From technical perspective it is certainly better to go for higher rate with -2s filters.

 

This question also has a slight variation: is sample rate family as important (do 48k-based stuff to 384k even if it requires lighter filters than instead doing 352k for everything)?

 

For PCM outputs I cannot imagine load becoming an issue. When I was testing upsampling RedBook to 768k PCM yesterday on 7700K, it was using less than 1% CPU time...

 

You can keep the rate family if you like to. From technical perspective it doesn't really make much difference. It does makes difference in terms of CPU load for higher DSD rates with non-2s filters. For example 44.1k PCM to 24.576 MHz DSD with poly-sinc is very heavy, 44.1k PCM to 22.5792 MHz DSD is not as heavy. With poly-sinc-2s not a problem with faster machines.

[ted_b]

Thanks Jussi. How about my question re: the HQP log listing of my dac's rate availability? Why would it list 768 when I have yet to get any music playing at that rate, let alone hiccups, dropouts, etc. Nothing plays...it decrements time but nothing emanates from the system. Is it just a atble in the ASIo driver, or some sort of analysis from ASIo or HQP? I am slightly interested to see what HQP (or is it an NAA function that reports back to HQP desktop's log)) in Linux would list.

[Superdad]

Thanks Jussi. How about my question re: the HQP log listing of my dac's rate availability? Why would it list 768 when I have yet to get any music playing at that rate, let alone hiccups, dropouts, etc. Nothing plays...it decrements time but nothing emanates from the system. Is it just a atble in the ASIo driver, or some sort of analysis from ASIo or HQP? I am slightly interested to see what HQP (or is it an NAA function that reports back to HQP desktop's log)) in Linux would list.

 

Ted:

I too have the Holo Spring and it does not play PCM768 (or 705.6) with my Mac. Display just goes to ------. But I can play 768 from same set up to iFi micro iDSD. Since Macs don't need drivers, I thought this might be a useful data point for you.

My understanding is that the DAC reports the capability only so that DSD512 will be available.

[Superdad]

I do. I'm letting it go for several hours before I go back to 3.15.

 

Well of course. The software has to have time to break-in!

[bogi]

I don't remember this ever happening back when I used a direct PC-DAC connection so I wondered if it was NAA network related. That was also many HQP versions back.

 

I started to use NAA 2-3 weeks ago and didn't observe that previously. It seems the uneven time counter and slider appears in the NAA case. No real trouble for me, rather curiosity.

[craighartley]

From technical perspective it is certainly better to go for higher rate with -2s filters.

 

It does makes difference in terms of CPU load for higher DSD rates with non-2s filters. For example 44.1k PCM to 24.576 MHz DSD with poly-sinc is very heavy, 44.1k PCM to 22.5792 MHz DSD is not as heavy. With poly-sinc-2s not a problem with faster machines.

 

Are you talking specifically about Red Book? Higher 44.1x rates (e.g. DXD) to 24.576 MHz DSD stutter badly with -2s on my 6700k + 1080GTX. (Using HQP 3.16)

 

 

Sent from my iPhone using Computer Audiophile

[Solstice380]

Are you talking specifically about Red Book? Higher 44.1x rates (e.g. DXD) to 24.576 MHz DSD stutter badly with -2s on my 6700k + 1080GTX. (Using HQP 3.16)

 

 

Sent from my iPhone using Computer Audiophile

 

My i7 6700K with GTX970 can do 44.1 to 48K x512 no problem with poly-sinc-2s. CPU ~22%. HQP just stops after trying to initialize with non -2s. I'll try some 88 and 176 source files later to see what happens.

[ted_b]

Ted:

 

My understanding is that the DAC reports the capability only so that DSD512 will be available.

 

If you mean DoP, then DSD512 would have to be carried on a 1.4Mhz carrier; 705k is for DSD256. In either case I don't use DoP anyway. And thanks for the Mac datapoint.

[pocarrie]

I compared 3.15 and 3.16 back and forth several times. (Lots of uninstallation and installation)

 

Still find the harshness existed in the 3.16 version. Much better than 3.15.1 but still worse than 3.15.

 

I'm using Roon with HQplayer, upsampling Tidal 44.1 and local DSD files to DSD512. Modulator ASDM 512+FS, filter: poly-sinc-xrt-2s. DAC: T+A DAC8 DSD.

 

Anyone feels the same with me?

Yes me too, it seems that 3.15 sounds more analog and less fatiguing.

[shadowlight]

Thanks Jussi. How about my question re: the HQP log listing of my dac's rate availability? Why would it list 768 when I have yet to get any music playing at that rate, let alone hiccups, dropouts, etc. Nothing plays...it decrements time but nothing emanates from the system. Is it just a atble in the ASIo driver, or some sort of analysis from ASIo or HQP? I am slightly interested to see what HQP (or is it an NAA function that reports back to HQP desktop's log)) in Linux would list.

 

I believe the issue is with the firmware/drivers reported by the USB controller. I get similar stuff from my DAC which has Amanero.

[mirekti]

I am using i7-7700 CPU and currently own a DAC which can only go do DSD128.

Is there a way I could test whether this CPU is strong enough to do upsampling to DSD512 without actually having DAC which supports it?

At the moment I only see in the options values up to those supported by the DAC.

[Quadman]

I am not sure if you can try higher rates as HQP only reports what the dac can do. The i7-7700 I am 100% certain will do at the very minimum DSD512 with the 2s filters and may well be able to do some auto rate with non-2s filters.

 

I am using i7-7700 CPU and currently own a DAC which can only go do DSD128.

Is there a way I could test whether this CPU is strong enough to do upsampling to DSD512 without actually having DAC which supports it?

At the moment I only see in the options values up to those supported by the DAC.

[tedwoods]

3.16 + xtr family filters = heaven!