HQ Player

[Outlaw]

1 hour ago, Miska said:

 

I'm just eager to utilize what ever they can offer, for improved sound quality...

 

Too bad they are so slow rolling out faster CPUs.

 

 

There are no changes in 4.7.1 that should have big impact on these things. I changed a few optimizations, but those affect Pro more (to be released some time later).

 

For me, things run the same as before on i7-8086K, i9-9900K(S) and i9-10900K. I have one new machine with the new i9-10850K which is very close to i9-10900K, but cheaper. Will test on that one later (it runs Win 10).

 

I have the 8086K also have not been able to do ASDM7EC since 4.6

[Miska]

1 minute ago, Outlaw said:

I have the 8086K also have not been able to do ASDM7EC since 4.6

 

In BIOS you have loaded "Optimized defaults", selected XMP memory Profile 1 if available, and use stock Windows 10 or Linux without "optimizations"?

 

[Miska]

For example 8086K is not even very close to limits with poly-sinc-ext2 + ASDM7EC. Core loads for cores 0 and 3 are around 84% during playback.

 

[Outlaw]

4 minutes ago, Miska said:

For example 8086K is not even very close to limits with poly-sinc-ext2 + ASDM7EC. Core loads for cores 0 and 3 are around 84% during playback.

 

Was able to do poly-sinc-xtr-mp with ASDM7EC but not since 4.7 releases

[Miska]

1 minute ago, Outlaw said:

Was able to do poly-sinc-xtr-mp with ASDM7EC but not since 4.7 releases

 

If you want latest hardware supported like for example the new Nvidia 30-series GPUs, it means development tooling needs to be updated. Or if I make a small code change somewhere to support new features like post-process plugins for headphone cross-feed and such. That may mean sometimes small positive, sometimes small negative changes in CPU load, sometimes because of increased RAM footprint or whatever.

 

It is not possible to keep everything unchanged, including old versions of development tools, while also introducing new things at the same time. In general, over time software grows and becomes more demanding. The load change in 4.6 -> 4.7 is in 1 - 2% region. If you were that close to the limits before, it may be enough to flip something over.

 

[StreamFidelity]

4 minutes ago, Miska said:

The load change in 4.6 -> 4.7 is in 1 - 2% region. If you were that close to the limits before, it may be enough to flip something over.

 

It's actually pretty simple. Since 4.7.0 many have the problem of not being able to run ASDM7EC anymore. A skilled developer looks at the problems and doesn't waste time explaining why it has stopped working.

[Account Closed]

19 minutes ago, Miska said:

 

What kind of machine is it? All my machines that did ASDM7EC before are still doing the same. With optimal BIOS settings and stock Windows 10, Linux and macOS.

 

I have a Intel i5 8400 on a ASUS Z370I MB and a 600 Watt PS (can't remember which) in a Streamcon Case. This is a passively cooled build with CPU heat-pipes to the fins. I went in and reset the BIOS to the defaults and re-loaded XMP Profile 1 as you suggested. There are no other optimizations expect that I turned off some unused services long ago. With 4.6 I could do ASDM7EC/DSD256/any 2s filter. With 4.7 (or 4.7.1) I can no longer get to this without dropouts every 10-15 seconds. I can now only get to ASDM7EC/DSD128/any 2s filter. Admittedly, I was on the edge with the modulator cores maxed out and running at 3.9 Ghz and core temps in the 70+ C range all the time but it did work.

 

Please don't misunderstand, I really don't care if I can still get to ASDM7EC /DSD256 or not. If I did, I would just stay at 4.6 and call it a day. To me on the Holo Spring 2 KTE, PCM 768/LNS 15 is every bit as good but just a slightly different sound profile. An added benefit for me using PCM is that I have the use of many more filters and channel balance and rate family conversion. Also, I don't have to worry about frying the CPU.

[Miska]

6 minutes ago, StreamFidelity said:

It's actually pretty simple. Since 4.7.0 many have the problem of not being able to run ASDM7EC anymore. A skilled developer looks at the problems and doesn't waste time explaining why it has stopped working.

 

Even skilled developer cannot put a square peg through a round hole. I have spent months to make it run as fast as possible. For you for example, the solution is to use BIOS settings that don't severely restrict the computing performance. Much simpler fix than me trying to spend (likely futile) attempt to try make the code run faster.

 

I can tell you that I have used my skills already to make ASDM7EC run at all, on any CPU, in realtime. Same actually goes for lot of other DSP code too.

 

Let's say I have i9-9900K, if I can make it run on mine, you should be able to make it run on yours. Or then it becomes hardware or BIOS setting problem. Not a software problem.

 

[Account Closed]

15 minutes ago, StreamFidelity said:

 

It's actually pretty simple. Since 4.7.0 many have the problem of not being able to run ASDM7EC anymore. A skilled developer looks at the problems and doesn't waste time explaining why it has stopped working.

Why not at least try the BIOS change and see if it will work for you. Just keep a BIOS config file so if you want to go back it will be easy. I did try it but it didn't help for me but my CPU can only reach 3.9 Ghz under load so I did not think it would help. Maybe you will be surprised.

[Miska]

In this case, the likely source of small load change are updated compiler versions. Yes, I did complain to the compiler developers. No, they likely don't consider HQPlayer important enough to spend a lot of time on for such a small change, compared to let's say Adobe Photoshop. OTOH, it is not even black and white, because the load got more consistent and stable with less fluctuations over time.

 

[LoryWiv]

To provide some balance I have noticed no change in usable filters / cpu limitation since 4.6 --> 4.7, runs as before at either 128 or 256 w/o dropouts. Admittedly I run ASDM5EC with my Sabre DAC, not ASDM7EC, however, as that sounds best. Clearly though there are others who have experienced changes. It may be worth knowing what distinguishes those who's usability has decreased post-upgrade from those who didn't at least to isolate any commonalities that can be addressed.

[Outlaw]

9 hours ago, Miska said:

 

In BIOS you have loaded "Optimized defaults", selected XMP memory Profile 1 if available, and use stock Windows 10 or Linux without "optimizations"?

 

Yes to all the above.

[StreamFidelity]

11 hours ago, Miska said:

I can tell you that I have used my skills already to make ASDM7EC run at all, on any CPU, in realtime. Same actually goes for lot of other DSP code too.

 

I apologize for my previous inappropriate comment. Your skills are beyond question to me and I really enjoy using the HQPlayer. 👍

[Miska]

4 hours ago, Outlaw said:

Yes to all the above.

 

Please try with poly-sinc-ext2 + ASDM7EC to DSD256, it should work. If it doesn't, there is some mysterious low level difference. In such case I would first check for BIOS updates. The motherboard where I have 8086K is Gigabyte Z390 AORUS MASTER. And RAM is Kingston HyperX Predator DDR4 2666.

 

If you are using CUDA offload, please check that you have latest Nvidia drivers. HQPlayer Desktop >= 4.7 uses CUDA 11 and requires newer driver version than 4.6. Also check without CUDA offload if you are getting dropouts with CUDA enabled.

 

[madman73]

On 9/4/2020 at 4:53 PM, Miska said:

 

PCM1704 is 24-bit component, so DAC Bits should be set to at most 24. Although it is not really linear to such precision, so you can try settings from 18 to 21 and check if you get improvement around these figures. 18 and 19 are pretty safe values, 20 and 21 are more on the border. To some extent depends on the chip grade.

 

Can you better explain which kind of improvement i should get? 
Until a few days ago the default setting was 32-bit, as the JLSound USB manages up to 32-bit, and I have never found it difficult to listen. Now I'm listening with 19-bit and it all sounds just as natural.

 

About gentooplayer, as I said, I am using it for compatibility reasons with my hardware, both for HQPlayer Embedded and for NAA.

It allows you to choose between RT and non-RT Kernel and to use ramdisk. It has a very intuitive web interface for those like me who are not familiar with linux commands.
Do you have any technical suggestions on which kernel type to prefer and how to use ramdisk to get the best out of hqp-embedded and NAA?

 

Thank you.

 

[EFIN]

I can run at my laptop easily dsd256 asmdc7 and all other filters to (except dsd512 with ec). Its something at your pcs where the problem is. I have i7-9750h and rtx2060. And my buffer is under 2ms without clipping even I have convolution on.

[luisma]

21 hours ago, Miska said:

I don't think it makes sense for me to limit my most advanced algorithms

Correct, we have so many options with HQP and we can use from the most minimalistic filters to the more advanced ones. There is to my knowledge no other digital conversion software with such capabilites, a real jewel. Keep up the good work Jussi

 

[Miska]

1 hour ago, madman73 said:

Can you better explain which kind of improvement i should get? 
Until a few days ago the default setting was 32-bit, as the JLSound USB manages up to 32-bit, and I have never found it difficult to listen. Now I'm listening with 19-bit and it all sounds just as natural.

 

Yes, all XMOS implementations I know of are 32-bit, some also support 16-bit inputs in addition, but none support the 3-byte 24-bit format (inefficient to implement in computer and in hardware). Another thing is about how many bits the DAC chip understands. In case of PCM1704, it is 24-bit converter, if you send there more, the rest will be just truncated, which creates distortion. To avoid the distortion, you need to dither/noise-shape to correct depth.

 

Then, to linearize a ladder DAC further, one can look to what depth the converter is actual linear. And then noise-shape to that depth. This way only the linear region is utilized, but without loss of dynamic range, which may instead actually increase.

 

1 hour ago, madman73 said:

Do you have any technical suggestions on which kernel type to prefer and how to use ramdisk to get the best out of hqp-embedded and NAA?

 

I have never used Gentoo player, but you can use realtime kernel and for NAA you can also use ramdisk since it doesn't store anything on the disk. For HQPlayer Embedded you shouldn't use ramdisk.

 

[ASRMichael]

5 minutes ago, Miska said:

 

Yes, all XMOS implementations I know of are 32-bit, some also support 16-bit inputs in addition, but none support the 3-byte 24-bit format (inefficient to implement in computer and in hardware). Another thing is about how many bits the DAC chip understands. In case of PCM1704, it is 24-bit converter, if you send there more, the rest will be just truncated, which creates distortion. To avoid the distortion, you need to dither/noise-shape to correct depth.

 

Then, to linearize a ladder DAC further, one can look to what depth the converter is actual linear. And then noise-shape to that depth. This way only the linear region is utilized, but without loss of dynamic range, which may instead actually increase.

 

 

I have never used Gentoo player, but you can use realtime kernel and for NAA you can also use ramdisk since it doesn't store anything on the disk. For HQPlayer Embedded you shouldn't use ramdisk.

 

@Miska what’s the reasoning why you don’t recommend Ramdisk/Ramroot for HQ embedded? 
 

Like me I use Euphony/HQP with setup in SQ for using RAMROOT. 

[sig8]

Deleted

[Miska]

7 minutes ago, ASRMichael said:

@Miska what’s the reasoning why you don’t recommend Ramdisk/Ramroot for HQ embedded? 
 

Like me I use Euphony/HQP with setup in SQ for using RAMROOT. 

 

Because HQPlayer Embedded stores information on disk and ramdisk is not persistent storage. In addition there's no point in doing that because the OS disk activity is minimal and the only notable activity is the content, for which there's no point in storing it on ramdisk because it would take huge amount of memory and long time to transfer (depending how large your library is).

 

Closest to persistent RAM storage is to use Optane M.2 storage for the OS and HQPlayer Embedded. Then it is pretty similar to ramdisk.

 

[Miska]

8 minutes ago, sig8 said:

I am trying to add files to HQP, but they just do not show up in HQP. I am going File>Library>Scan, and then scanning a folder from local C drive, but they just do not show up.

 

Maybe permission problem, or files being in unsupported format?

 

9 minutes ago, sig8 said:

Drag-n-drop also does not work. Strange?

 

This should show up as errors in the HQPlayer main window status bar.

 

[sig8]

Deleted

 

[AudioDoctor]

@Miska Any ideas if your NAA image on a Raspberry Pi 4 will continue to work when Roon enforces their Roon Certified program on the 21st?

[EFIN]

11 hours ago, Miska said:

 

Because HQPlayer Embedded stores information on disk and ramdisk is not persistent storage. In addition there's no point in doing that because the OS disk activity is minimal and the only notable activity is the content, for which there's no point in storing it on ramdisk because it would take huge amount of memory and long time to transfer (depending how large your library is).

 

Closest to persistent RAM storage is to use Optane M.2 storage for the OS and HQPlayer Embedded. Then it is pretty similar to ramdisk.

I think if you own fast nvme you dont get anything from optane, bcuz good ram and nvmes are so fast that it doesnt help in that. Buy one good and big nvme.