HQ Player

[bogi]

5 minutes ago, Kalpesh said:

do you confirm poly-sinc-gauss-long for classical music

You can try ext2 with classical music, it could give you more feeling of space. Although gauss-long could give you more detail on instrument timbre. Use what you like more. :)

[Miska]

8 minutes ago, Kalpesh said:

do you confirm poly-sinc-gauss-long for classical music, Digital recording from -79, not digitized ? 

 

I use my Holo DSD256 with ASDM7ECv2 99.9 % of the time ; do I understand correctly that in your opinion the 0.1% has no technical justification even with digital recordings made prior to the SDM era or digitized with Pacific Microsonic ?

 

Pacific Microsonics didn't exist in 1979... But it doesn't matter for output format whether the source is from pre-SDM era or not.

 

Choice of upsampling filter is more depending on the source content and one's preferences. Output format and modulator depend on the used DAC.

 

If you want to use PCM output, you can also use 1.5M output at 20-bit with LNS15 shaper. Or 705.6/768k output at 20-bit with NS9 or NS5 shaper.

 

[semente]

What else can cause drop-outs other than lack of processing power?

 

My i3 2018 Mini can do ext3 + ASDM5EC without hiccups (w/ CPU @ 82%) but not ext2 + ASDM5ECv2 (w/ CPU @ 62%).

 

My network is Gigabit wired and my NAA is a microRendu 1.3.

[Miska]

21 minutes ago, semente said:

What else can cause drop-outs other than lack of processing power?

 

My i3 2018 Mini can do ext3 + ASDM5EC without hiccups (w/ CPU @ 82%) but not ext2 + ASDM5ECv2 (w/ CPU @ 62%).

 

My network is Gigabit wired and my NAA is a microRendu 1.3.

 

By the way, check that you are using latest Intel Mac build. I updated the build yesterday because there was one mistake in the build process. Latest has size 305641926 and SHA256 checksum:

b45610c04f18102c78a31f07e5f95de9dba1aefcc2f045af973a24b563eda7db

 

It is different load pattern to use heavier filter vs heavier modulator. When playback begins stuttering, you cannot trust the CPU load figures anymore. Per-core load of ECv2 is roughly 10 - 15% higher than EC. Also things like CPU cache sizes affect this. But EC is already really good, so no need worry too much if ECv2 doesn't run.

 

From Acitivty Monitor, open the per-core load graphs. It is quite informative usually.

 

[semente]

19 minutes ago, Miska said:

 

By the way, check that you are using latest Intel Mac build. I updated the build yesterday because there was one mistake in the build process. Latest has size 305641926 and SHA256 checksum:

b45610c04f18102c78a31f07e5f95de9dba1aefcc2f045af973a24b563eda7db

 

It is different load pattern to use heavier filter vs heavier modulator. When playback begins stuttering, you cannot trust the CPU load figures anymore. Per-core load of ECv2 is roughly 10 - 15% higher than EC. Also things like CPU cache sizes affect this. But EC is already really good, so no need worry too much if ECv2 doesn't run.

 

From Acitivty Monitor, open the per-core load graphs. It is quite informative usually.

 

 

Thanks for the suggestion. Unfortunately 4.15.4 is even worse than 4.15.3, now I can't even do ext2 + ASDM5EC without hiccups let alone ext3 + ASDM5EC. I'm back to 4.15.1 for the time being.

 

I think that I need to get a 2018 i7 or the M1...

[Miska]

11 minutes ago, semente said:

Thanks for the suggestion. Unfortunately 4.15.4 is even worse than 4.15.3, now I can't even do ext2 + ASDM5EC without hiccups let alone ext3 + ASDM5EC. I'm back to 4.15.1 for the time being.

 

With that latest build and Multicore DSP set to grayed (auto)? I don't know how many cores your model has, but if it's low on cores, also try turning Multicore DSP off.

 

11 minutes ago, semente said:

I think that I need to get a 2018 i7 or the M1...

 

I think M1 models are certainly more future-proof...

 

[Kalpesh]

1 hour ago, Miska said:

 

 it doesn't matter for output format whether the source is from pre-SDM era or not.

 

 

 

 

How many actual bits had the ADC/digital recorder following the microphones back then ?

I had in mind that more approximations were done back then than what can be achieved nowadays ; and that in that line of thought I could take the analogy that when I come home, things that I don't know what to do with are dumped in the left drawer of that piece of furniture to keep the place looking tidy and that maybe R2R would know better in which "drawer" the approximations made by R2R ADC back then were made.... just being very candid but I hope I convey the idea correctly and that you will enlighten us  further why some types of reconstruction of the initial signal work better than others with some recordings and/or for some ears

[semente]

46 minutes ago, Miska said:

With that latest build and Multicore DSP set to grayed (auto)? I don't know how many cores your model has, but if it's low on cores, also try turning Multicore DSP off.

 

It's a lowly i3 with only 4 cores. 😕

Interestingly I turned off Multicore DSP on 4.15.1 and it started hiccupping. When it's grey, it works fine.

[Miska]

46 minutes ago, Kalpesh said:

How many actual bits had the ADC/digital recorder following the microphones back then ?

 

Usually 14 - 16 bits. All wasn't necessarily PCM, but instead delta-coding (before sigma part was later added). And the digital data was then stored on a tape, typically U-matic. This was then used for delta-sigma storage too, see more details here:

https://en.wikipedia.org/wiki/PCM_adaptor

 

I remember dealing with U-matics... 😅

 

In late 80's, DAT recorders largely replaced such.

 

Many of first CD players were 14-bit with only single channel converter, so left and right channels were converted using the same DAC stage and multiplexer switching between the channels on the output.

 

Like now mobile phone and other digital microphones are PDM (aka DSD) right from the microphone chip. (now you can integrate microphone and it's ADC)

 

46 minutes ago, Kalpesh said:

I had in mind that more approximations were done back then than what can be achieved nowadays ; and that in that line of thought I could take the analogy that when I come home, things that I don't know what to do with are dumped in the left drawer of that piece of furniture to keep the place looking tidy and that maybe R2R would know better in which "drawer" the approximations made by R2R ADC back then were made.... just being very candid but I hope I convey the idea correctly and that you will enlighten us  further why some types of reconstruction of the initial signal work better than others with some recordings and/or for some ears

 

I don't know what you are after. R2R was just used in DACs in the old days because it was cheaper due to lacking DSP capacity to do anything better. Old recordings work relatively better on R2R than newer ones due to their inherent high noise floor and other shortcomings hiding some of shortcomings on the reconstruction side. While SDM performs the same always, portraying all the shortcomings in the old recordings.

 

[Miska]

12 minutes ago, semente said:

It's a lowly i3 with only 4 cores. 😕

Interestingly I turned off Multicore DSP on 4.15.1 and it started hiccupping. When it's grey, it works fine.

 

But in 4.15.4?

[Kalpesh]

9 minutes ago, Miska said:

 

Usually 14 - 16 bits. All wasn't necessarily PCM, but instead delta-coding (before sigma part was later added). And the digital data was then stored on a tape, typically U-matic. This was then used for delta-sigma storage too, see more details here:

https://en.wikipedia.org/wiki/PCM_adaptor

 

I remember dealing with U-matics... 😅

 

In late 80's, DAT recorders largely replaced such.

 

Many of first CD players were 14-bit with only single channel converter, so left and right channels were converted using the same DAC stage and multiplexer switching between the channels on the output.

 

Like now mobile phone and other digital microphones are PDM (aka DSD) right from the microphone chip. (now you can integrate microphone and it's ADC)

 

 

I don't know what you are after. R2R was just used in DACs in the old days because it was cheaper due to lacking DSP capacity to do anything better. Old recordings work relatively better on R2R than newer ones due to their inherent high noise floor and other shortcomings hiding some of shortcomings on the reconstruction side. While SDM performs the same always, portraying all the shortcomings in the old recordings.

 

seems you nailed it ! I agree that SDM works better with the vast majority of recordings I listen to, and I don't even try the PCM R2R route of my Holo with newer recordings but, yes, I happen to find that some old recordings work better on R2R, thank you for explaining why ! 

[semente]

12 minutes ago, Miska said:

 

But in 4.15.4?

 

On 4.15.4 I get dropouts with ext2 + ASDM5EC with Multicore DSP off and also grey.

 

With 4.15.1 I do ext3 + ASDM5EC so don't worry. I'll keep it until I have replace the mini.

[Zauurx]

On 1/7/2022 at 11:47 PM, Miska said:

 

No it is not, HQPlayer is specifically putting specific things on core 0. If you are not using stock Windows and using something like AO, Fidelizer or something else to tamper with Windows or HQPlayer, your problems are because of such tampering.

 

I don't use Fidelizer but AO without problems.
However you were right.  😉
There was a ProcessLasso setting interfering. I had to edit the configuration file by hand and delete all references to HQPlayer.
Now, back to DSD256... in 48 and even with the ASDM5ECv2 !! 👍
The only thing that blocks, are the 88/24 files. In 44 or 96, no problem but the 88... nada !

Well, there are few in my audio database and in Qobuz.

Thanks Miska for the support.  👏

Here we go again... we don't change anything ! 

 

 

[Bob Stern]

MacOS system requirements:

 

The web page <www.signalyst.com/consumer> now says MacOS 11 (Big Sur) is the minimum requirement for Desktop.  Nevertheless, HQP 4.15.4 is running fine for me in MacOS 10.15 (Catalina).

 

Jussi, are you building Desktop for compatibility with a lower version of MacOS, but merely stating that you do not promise tech support for more than one version of MacOS behind the current version?

[Miska]

26 minutes ago, Bob Stern said:

The web page <www.signalyst.com/consumer> now says MacOS 11 (Big Sur) is the minimum requirement for Desktop.  Nevertheless, HQP 4.15.4 is running fine for me in MacOS 10.15 (Catalina).

 

Technically, it could run from 10.14 up. But some (Universal) components have macOS 11 baseline set.

 

26 minutes ago, Bob Stern said:

Jussi, are you building Desktop for compatibility with a lower version of MacOS, but merely stating that you do not promise tech support for more than one version of MacOS behind the current version?

 

Current toolkits set baseline 10.14 for x64 components and 11 for Universal/arm64 components.

 

Oldest macOS I currently have is 10.15 and I didn't test latest release on it yet. I need to locally set up remote desktop on it first. I generally test HQPlayer only on latest and latest - 1 releases.

 

I have two Intel Macs and one M1 Mac. So that also puts limits on my testing.

 

[Zauurx]

And now... I've dared! ASDM7ECv2 !! and yes, with a core i5-8400, 8th generation. 🤩

THANKS !!!

 

It's fine... 
 Win10 (hyper light  without display), I'm not able to monitor temperature or load anymore... but it works without any blank in 44/16 or 96/24.

 

 

[bogi]

13 minutes ago, Zauurx said:

And now... I've dared! ASDM7ECv2 !! and yes, with a core i5-8400, 8th generation. 🤩

Nice! :) Although not unexpected for me since I am running the same on less performant CPU.
Yours has 2 physical cores more and higher CPU boost frequency than mine.
https://cpu.userbenchmark.com/Compare/Intel-Core-i7-6820HQ-vs-Intel-Core-i5-8400/m43500vs3939

[shadowlight]

@Miska has anyone else reported random reboots when using the 4.15.4 version of desktop and client?  My system has rebooted multiple times when I use it with Qobuz streaming.  I have not tried local library.  Any input on what I could check to potentially narrow down the problem.  I will try using just the client with my embedded setup to narrow down if it's client or desktop software.

 

The system that I am using is my primary win10 system in my office which works just fine as long as I do not run HQP and client.

[bogi]

3 minutes ago, shadowlight said:

My system has rebooted multiple times

Nobody reported such a thing till now. It seems to me like an issue with your OS. Look at Event Viewer - System Log and Application Log - to sort out what's the source of errors.

[Miska]

Which reminds me... I spent one day chasing a crash bug in HQPlayer, appeared only on my i5-11600 machine... Which in the end turned out to be RAM problem, at one point I started suspecting such and booted to memtest86. Which reported errors pretty quickly. Fixing the RAM also fixed those crashes...

 

HQPlayer is pretty heavy on RAM.

 

One possibility is some out of memory situation, but this shouldn't crash the system.

 

[shadowlight]

7 minutes ago, bogi said:

Nobody reported such a thing till now. It seems to me like an issue with your OS. Look at Event Viewer - System Log and Application Log - to sort out what's the source of errors.

All I am seeing is system shutdown unexpectedly in the event viewer in the system log with bugcheck 0x00000133 and nothing in the application log around the time stamp when the system rebooted.

[shadowlight]

10 minutes ago, Miska said:

Which reminds me... I spent one day chasing a crash bug in HQPlayer, appeared only on my i5-11600 machine... Which in the end turned out to be RAM problem, at one point I started suspecting such and booted to memtest86. Which reported errors pretty quickly. Fixing the RAM also fixed those crashes...

 

HQPlayer is pretty heavy on RAM.

 

One possibility is some out of memory situation, but this shouldn't crash the system.

 

I will download memtest86 and see if I am seeing error messages.  The system in question is old lenovo i3-4130t with 16gb of memory.

[bogi]

4 minutes ago, shadowlight said:

All I am seeing is system shutdown unexpectedly in the event viewer in the system log with bugcheck 0x00000133 and nothing in the application log around the time stamp when the system rebooted.

You probably mean system crash and not shutdown, which is a controlled process and takes some seconds, sometimes a minute.

 

Unexpected system crash can be caused for example by some device driver malfunction. Try to find out which devices are in use only in the crash scenario.

 

You could try to exchange some components if possible. For example to use other USB port to connect your DAC, try anything what you can do in alternative way. It may give you more information.

 

You can also activate HQPlayer log and then look at it what's the last message before crash.

 

And of course you can check and fix possible system inconsistency by:

sfc /scannow

Dism /Online /Cleanup-Image /RestoreHealth

More info for example: https://rejzor.wordpress.com/2016/06/18/windows-10-system-integrity-check-sfc-dism/

 

[bogi]

18 minutes ago, shadowlight said:

One possibility is some out of memory situation, but this shouldn't crash the system.

With 16GB it seems to be rather improbable that you could run out o memory (if you are not running yet something else). You can easily check available memory by opening Task Manager Performance tab or opening Performance Monitor while running HQPlayer Desktop + Client.

Memory error is of course other case. To run RAM check is good idea.

Try to run Desktop without Client, try local files, try your integrated sound card, anything you can alter to get more information.

[Miska]

48 minutes ago, bogi said:

With 16GB it seems to be rather improbable that you could run out o memory (if you are not running yet something else).

 

HQPlayer can now have pretty steep memory usage, due to (requested) initialization caches and streaming features. It is not unusual to run out of RAM with 16 GB. But I have not yet experienced such with 32 GB.