HQ Player

[Miska]

@Miska I want to report that DSD64 to DSD128/256 conversion may not be working on 3.12.0. I had the same issues on a windows desktop machine (Win 10, 3.5 GHz i7, no CUDA, 32 Gig RAM). I did not have the problem with the previous version on the Windows desktop. Then I reverted to old version (3.11.0), and I do not have the choppiness. I understand this is in beta, but I hope you can confirm if this is an issue.

 

Yes, thank you for the report, this has been fixed for the next release...

[Sam Lord]

Sorry going OT here, but I recently looked at Miska's many (persuasive) posts on digital vs. analog volume controls in that thread:

digital-vs-analogue-volume-control/

Is there any change to the recommendation that HQPlayer's volume control not be used as a normal level control? I have an Oppo 105D as a DAC directly driving my amps, and it has a mute button for safety. Should I use HQP's volume control? Is it easy to control with MUSO or any other application? Thanks!

 

Separately, I also am very curious how the new multibit Schiit DACs will fare against the currently popular delta-sigma DACs like the Exasound E22 when the latter is run with HQP's closed-form filters. This is a very exciting time for digital playback.

[Chodi]

Sorry going OT here, but I recently looked at Miska's many (persuasive) posts on digital vs. analog volume controls in that thread:

digital-vs-analogue-volume-control/

Is there any change to the recommendation that HQPlayer's volume control not be used as a normal level control? I have an Oppo 105D as a DAC directly driving my amps, and it has a mute button for safety. Should I use HQP's volume control? Is it easy to control with MUSO or any other application? Thanks!

 

Separately, I also am very curious how the new multibit Schiit DACs will fare against the currently popular delta-sigma DACs like the Exasound E22 when the latter is run with HQP's closed-form filters. This is a very exciting time for digital playback.

 

I'm sure Miska will answer your post but I wanted to mention that I use his volume control in HQP daily and I find that as long as you don't go crazy reducing the volume by more than 20db it works perfectly with no noticeable degradation. I often have it set at -5 to -10db with no apparent degradation.

 

Your comment on multi bit dac was interesting. You might be aware that is where all this digital stuff started. In the beginning, all dacs were multi bit dacs. First 14 bit (the first Phillips/Sony) then 16 then 20 bit. The transfer to sigma delta dacs came much later and was more a matter of economy when they first appeared. It was something like the Beta vs VHS thing back then. I think it was Matsushita that started the 1 bit thing. I am not saying one is superior to the other simply that multi bit dacs are certainly nothing new.

[Sam Lord]

...as long as you don't go crazy reducing the volume by more than 20db it works perfectly with no noticeable degradation... ...You might be aware that is where all this digital stuff started. In the beginning, all dacs were multi bit dacs...[I remember. -SL]

 

Thanks Chodi. Then I assume you don't use a the volume control of your Auralic Taurus. But 20dB isn't much range to work with if you often listen at live (unamplified concert) levels. I have my system all the way up for lots of songs, which usually gives 98-100dB peaks at my listening position. Those are intersample peaks because I've reset my HQP max output to -6dB. And I set my Oppo to a max level that corresponds to my amp's never receiving a signal that clips them, though of course they *could* get a garbage signal like a 50% duty cycle square wave to melt things after a while! I do rest my ears in between those numbers, but still a song with 78dB peaks and 65dB average is too loud for some situations.

 

Okay, I just found that the HQP manual is still in use from 3.4 and says "Never use software based volume control as a sole mean[sic] for adjusting volume." But then it says "Always limit the maximum possible volume to reasonable levels by using suitable hardware adjustment." Gawd, that's worded like our notorious Second Amendment! Two excellent sentences combined to confuse.

 

That knocks out any usefulness for digital volume control with HQP until some future version fixes the problem. Or did Jussi only mean we need an external *mute* for safety? I have one on my Oppo, and even if I replace that with the Bifrost, I could create remote mutes for my Hypex amps. Why go on about the accuracy of digital VC if you can't use it alone? Really, putting any kind of wide-range attenuator in series is exactly what to avoid!

 

I vaguely remember this discussion way back in early HQP posts but I can't find them. There were concerns about software that would screw with HQP on restarts and begin at 0dB attenuation. But if I set max gains on my DAC and/or amp to a level that won't cause clipping, I should be safe. OTOH you wouldn't want to leave your stereo loud and vulnerable to electrical glitches when you're out of the house, it could really disturb your pets and neighbors.

[Chodi]

Sam,

 

I'm going to respond to your post without copy the entire thing here. Some time ago Miska recanted his position on the digital volume control in HQP. He no longer advised against using it. He always said that the volume control in HQP had to be set at least to -3db for necessary headroom. In my post above I was simply pointing out that I have no audible degradation using the volume control in HQP. I set the volume control on my Taurus at a comfortable level for most listening and rarely touch it. I do on occasion reduce the volume on my dac by a small amount, perhaps -3 to -6db. That is a digital volume control in itself that is really part of the Sabre dac. There is a long and detailed position paper from the folks that make the Sabre dac about how the use of their control will not degrade the sound within reasonable limits. You can refer to their web site for that if you wish.

 

My situation is unusual in that I listen at home only with iem's. That is because I can no longer bear the weight of full size headphones for prolonged listening. That was the result of an accident about 18 months ago. My setup is a bit unique and believe me if I could hear a negative difference using the HQP volume control I would not be using it. So you can surmise from all this that it works for me but you may test it with your own equipment and judge for yourself.

[Argopo]

CoreAudio wants to manage buffers on it's own, so it is not available on OS X...

 

Is there a work around for this? I am still experiencing infrequent dropouts.

 

I am able to change the buffer size in JRiver, so using it more than HQPlayer. But, would prefer to use HQP as my primary player.

[Miska]

I am able to change the buffer size in JRiver, so using it more than HQPlayer. But, would prefer to use HQP as my primary player.

 

Probably it is JRiver's buffer, not the CoreAudio's hardware buffer... The setting in HQPlayer refers to the hardware buffer size.

[Miska]

Okay, I just found that the HQP manual is still in use from 3.4 and says "Never use software based volume control as a sole mean[sic] for adjusting volume." But then it says "Always limit the maximum possible volume to reasonable levels by using suitable hardware adjustment." Gawd, that's worded like our notorious Second Amendment! Two excellent sentences combined to confuse.

 

That knocks out any usefulness for digital volume control with HQP until some future version fixes the problem. Or did Jussi only mean we need an external *mute* for safety? I have one on my Oppo, and even if I replace that with the Bifrost, I could create remote mutes for my Hypex amps. Why go on about the accuracy of digital VC if you can't use it alone? Really, putting any kind of wide-range attenuator in series is exactly what to avoid!

 

From signal fidelity point of view, there's no problem to use HQPlayer's digital volume for what ever adjustment range necessary.

 

Reason for wording things the way they are written is safety. Any software/computer related volume control is prone to accidents or unexpected behavior, so what I wanted to emphasize is that even if software volume control fails, the maximum possible output level should be limited to reasonable listening level range. Just to avoid damage to the system and ears. For safety reasons there's the maximum/limit volume setting in HQPlayer. But there may be bugs in the software, or the OS may decide (for what ever reason) to suddenly put out "*bling* you've got new email" at full volume.

 

As an example, I have exaSound DAC volume set to 0 dB all the time because it doesn't keep headphone and line out volumes separate (unlike Mytek) and I adjust volume for headphone listening only from HQPlayer where the setting is usually somewhere between -20 and -30 dB. exaSound DAC's output is at the moment connected to a fully analog pre-amp with resistor ladder volume control.

 

For using digital volume in HQPlayer my recommendation for "calibration procedure" has been:

1) First set analog volume control to minimum

2) Set HQPlayer volume to -3 dBFS

3) Play some music and adjust analog volume control to highest useful comfortable listening level

4) Turn down the volume in HQPlayer to the intended listening level

5) You can adjust volume control range minimum level to lowest useful level in HQPlayer settings, this keeps the adjustment knob comfortable to use, you can also set the maximum level to something between -3 and -1 to avoid inter-sample overs even when the knob is turned to max.

6) You can fine tune analog volume over time to reach the best setting

 

This combination usually gives best practical performance and usability.

 

It may be possible to safely use some low-gain or adjustable gain power-amps like Benchmark AHB2 with DAC and pure digital volume control. But this depends on the overall system.

[Miska]

"Some other...R2R ladder DACs" perhaps including Yggdrasil? (Obviously not NOS since it uses its own closed-form filter.)

 

Maybe I'll order the BiForst MB since it becomes NOS at 4x rates and see how things work out with it...

 

Edit: Any thoughts as to why the combination of closed form filtering and no SDM seems to work?

 

I don't have any good idea yet why. The ordinary measurements like THD and IMD don't differ much, there are some relative differences between different harmonics but nothing major. But the jitter (Jtest signal) spectra is wildly different between different filter choices, for some strange reason. This may be the ghost Peter has been chasing with software + NOS1 too. Any upsampling to 352.8/384k is still several orders of magnitude better performance than running 44.1k NOS mode. So there's the giant step and then small tuning. But I still need to do more measurements and testing to have a better picture.

 

With SDM DACs the jitter spectra is usually very consistent and doesn't change with filters.

[Miska]

I'm looking forward to trying the new beta!

 

Now the beta2 is out. I had a packaging mistake the previous beta which caused part of the CUDA trouble. I've now fixed bunch of bugs, done some optimizations and tested the new beta on friend's machine that has only the official nVidia drivers installed but nothing else (no toolkit installation) and it now worked fine.

 

At the beginning of every track, there's now status bar message for three seconds displaying offload status.

[Sam Lord]

Sam, I'm going to respond to your post without copy the entire thing here.

 

Thanks Chodi, that's what I do if my post comes soon after

 

...In my post above I was simply pointing out that I have no audible degradation using the volume control in HQP. I set the volume control on my Taurus at a comfortable level for most listening and rarely touch it....

From signal fidelity point of view, there's no problem to use HQPlayer's digital volume for what ever adjustment range necessary.

 

Reason for wording things the way they are written is safety. Any software/computer related volume control is prone to accidents or unexpected behavior, so what I wanted to emphasize is that even if software volume control fails, the maximum possible output level should be limited to reasonable listening level range...

 

Thanks Chodi and Jussi for your excellent explanations. I guessed correctly. I urge that in the next manual revision Jussi, you expand the writing in the volume control section so people fully understand what you have said above. This is very good news: The DACs I'm looking at max at 2Vrms output unbalanced, the standard input for most amps at 1% distortion. I'll try my Bimby straight into the amp for a while.

 

I only recently put HQP at a lower setting than 0dB, during illnesses of the past year I had reset it wrongly. In recent listening, I did *think* that the -6dB max HQP output setting sounded better than -3dB, which *definitely* sounded better than 0dB. The whole system was shouty and I was blaming my amps, though they still are suspect. I don't know just how high those intersample peaks go ("Only your Signalyst knows for sure!") And now I need to recalibrate my ears before switching in the Bimby. Thank you again gentlemen.

[Chodi]

I can report that this new Beta 2 is working perfectly much better than the first version. For whatever reason cpu usage is down even more with the CUDA offload than the first version. That is a welcome improvement. The indicator for the offload is also working as advertised. As always Miska has done an exceptional job. If we were handing out gold stars this version would get 5.

[bibo01]

I tried v3.12beta2 on Windows.

I can playback from local disk.

If I drag'n'drop or choose a file from NAS, instead, HQPlayer goes in crash - it endlessly tries to load the file.

The log reports nothing after dropping the file.

[AnotherSpin]

Now the beta2 is out.

Beta2 doesn't play dff files on Yosemite OS (no problems with same files with beta1).

[Chodi]

Beta2 doesn't play dff files on Yosemite OS (no problems with same files with beta1).

 

I'm loving this. Beta 2 is working perfectly for me on Windows 10 and you guys are pulling your hair out. Just can't please everyone. Miska has created so many permutations of this program that it must be a nightmare to test everything. For my application this is the best version of HQPlayer ever.

[KMan]

@Miska, I tried v3.12 beta 2, On Windows 10 with CUDA, playing to a NAA I get no sound, it looks like it is processing (based on network and CPU). On Mac Yosemite, with CUDA playing to NAA, I get sound but it stutters. It does not matter which file I play (flac/dsf) or which rate. I tested NAA on both AudioLinux and Win10. I have not tried local playb back.

 

@Chodi, Are you playing to a directly connected DAC or through NAAA from your windows 10 PC?

[Chodi]

@Chodi, Are you playing to a directly connected DAC or through NAAA from your windows 10 PC?

 

My computer is connected to my dac through usb directly. Never had the need or the desire for NAA. Playing redbook upscaled to DSD256 I am now showing only 12% cpu load with closed form. That is a massive improvement over any previous version. It is safe to say that the CUDA offload was not working properly before. Now it is offloading most of the processing to my gpu. Through Gpuz I can see the offload and my Nvidia card is coasting with what it thinks is a lite load. I am a happy camper.

[bibo01]

I tried v3.12beta2 on Windows.

I can playback from local disk.

If I drag'n'drop or choose a file from NAS, instead, HQPlayer goes in crash - it endlessly tries to load the file.

The log reports nothing after dropping the file.

Sorry Miska, but it now works fine both from local and NAS.

The NAS problem was probably a system issue.

[KMan]

Anyone else having issues with 3.12 beta2 when using with NAA?

[AnotherSpin]

I'm loving this. Beta 2 is working perfectly for me on Windows 10 and you guys are pulling your hair out.

 

Most of my hairs still here. Anyway, thank you for caring.

[Miska]

Beta2 doesn't play dff files on Yosemite OS (no problems with same files with beta1).

 

I've now found this issue and fixed it, since the fix is one line code change I'll probably make a new build later today and call it beta3 as quick fix.

[AnotherSpin]

I've now found this issue and fixed it, since the fix is one line code change I'll probably make a new build later today and call it beta3 as quick fix.

Thank you!

 

Also, for your notice: beta1 (closed form, ASDM7) is working generally well in my mac Yosemite environment. Still, in some rare cases I am clicking "play" button several times to start playback. Some stuttering happened in one particular case on very large FLAC file (one track for whole album) which was playing without stuttering by official non-beta build.

[KMan]

I've now found this issue and fixed it, since the fix is one line code change I'll probably make a new build later today and call it beta3 as quick fix.

Miska, could you please confirm if beta3 would also fix the issue of playback through NAA.

[jabbr]

beta2 working much better.

 

I can: closed form, ADSMV7, DSD512 whether or not I GPU off load to 760

also poly-sinc-mp-2s either way but:

poly-sinc-mp stutters at DSD512 regardless of GPU offload or not, buffer times, etc. CPU load roughly 220% regardless. this load seems nicely better than v11 regardless

 

Jon

[Samuel T Cogley]

My system:

 

ASUS X99 Deluxe MB, Intel i7 5930k CPU, 64GB RAM, nVidia GTX 990 GPU, Windows 7

 

First of all, CUDA offload appears to be working because I (very, very briefly) saw "offload: resampler=enabled" on the status bar.

 

But now, "closed-form" and "closed-form-fast" simply won't start up at DSD512. They seem to work just fine at DSD256 and lower. On beta 1, closed-form-fast worked just fine with no stuttering and closed-form would at least output stuttering sound.

 

Note: The application doesn't totally freeze when I attempt closed-form[-fast]/DSD512. But I have to close and re-open it for it to function again after attempting those combinations.