HQ Player

[Yviena]

24 minutes ago, Miska said:

 

All the three poly-sinc-long filters take about the same time to initialize. But it takes insanely long if you try to initialize it for something like 44.1 kHz -> 768 kHz rate conversion unless you have a lot of fast CPU cores... So here the adaptive output rate is your friend really.

 

You are not the first one to say about the 'i' and 'l' difference. I just didn't want to start redoing the naming scheme due to this case.

 

Yeah Poly-sinc-LP 48k PCM to DSD256 EC7 takes more than 5 minutes to initialize, but HQPlayer is not actually using all cores when doing it seems to exclusively only use SMT threads so maybe this is why it takes so long.

 

Also it seems that pressing ESC to cancel the initialization just seems to freeze HQPlayer as it is still consuming 50% cpu usage   even if it has been canceled.

[Miska]

36 minutes ago, pcmchild said:

How can I input from any external physical source to HQP and get (without resampling) the source original sample rate (automatically detected, without having to to set manually that rate on HQP)? Any method is ok for me, WASAPI, ASIO, etc.

I understand that this not working may be fault of the input port device/driver, so can you tell me any input port devices+drivers you tested and works for this purpose (for windows)?

 

I haven't got time to play with this on Windows yet. With WASAPI it won't work as it doesn't have support for such functionality.

 

With ASIO it can theoretically work, but likely not all hardware or drivers support it. It is more likely to work with PCIe hardware than with USB, since on USB it needs some additional non-standard commands between host and device. Finding solution that actually works may be hard and expensive exercise.

 

On Linux I have it working with RME ADI-2 Pro as input device (after I added the needed custom things to the driver) on HQPlayer 4 Embedded. Same input device specifications also work on HQPlayer 4 Desktop, however the configuration cannot be done using Settings dialog alone, because it is too complex for that. So some manual configuration file editing with text editor is needed.

 

43 minutes ago, pcmchild said:

I am using Realtek driver 2.82. And as I don't find realtek asio drivers, for asio I am using ASIO4ALL. I am suspecting ASIO4ALL may be the culprit here. Did you ever use ASIO with Realtek chips? What asio drivers did you use?

 

ASIO4ALL is not a real ASIO driver, it operates on top of KS/WASAPI and represent ASIO interface to applications. So it has combined limitations of both ASIO and WASAPI. So you could as well use WASAPI for input side too.

 

I don't use any Realtek interfaces.

 

At the moment I have RME HDSPe AIO cards in two Windows machines. From these, inputs work at fixed rate using WASAPI. There is also potential that auto-detection would work as the hardware supports it. But I'm not sure if the driver does, based my discussions with RME, and I haven't got time to test it.

 

1 hour ago, pcmchild said:

With WASAPI input to HQP, HQP can receive any sample rate (it seems windows is resampling to the requested rate), but HQP does not accept to play 0 rate, althoug it accepts ENTER and lists it in the playlist. However I am not sure if Windows is first resampling the original to Windows configured rate, and only then from that to HQP requested rate. So I am not sure if windows is not resampling twice.

 

With ASIO input to HQP, HQP  can also receive any sample rate it specifies. The 0 (auto detect) sample rate value works, but not with the file sample rate, but with that last specified sample rate in the audio: statement.  So if before the 0 statement I enter an audio:default/48000/2 statement, then the 0 statement will use 48000. Note I do not have to play the audio:48000, just press Enter so that it goes to the playlist, and if then I enter an audio:0 statement and play it, the used rate will be the 48000. This is valid for any value not only 48000. And this value is kept even after I restart the PC, so it is permanently stored somewhere. So somewhere it is resampling to the rate I specified. Who do you think is doing the resampling and why?

 

It shouldn't be resampling twice, just once. But it is likely Windows audio engine doing it. And WASAPI is likely falling back to Shared Mode, because two applications cannot simultaneously use the same hardware in Exclusive Mode.

 

[Miska]

1 hour ago, Yviena said:

Yeah Poly-sinc-LP 48k PCM to DSD256 EC7 takes more than 5 minutes to initialize, but HQPlayer is not actually using all cores when doing it seems to exclusively only use SMT threads so maybe this is why it takes so long.

 

It is then working as it should. It doesn't make any difference which of the two thread siblings is used. Using both doesn't really change the time taken either, because each core of course has only one execution unit. SMT threads are just virtual aliases of the same core and only thing they double is the register bank.

 

Running it on all threads you would get 100% CPU load instead of 50%, but the time taken would be the same, +- few %.

 

1 hour ago, Yviena said:

Also it seems that pressing ESC to cancel the initialization just seems to freeze HQPlayer as it is still consuming 50% cpu usage   even if it has been canceled.

 

There is no way to cancel the initialization. You need to wait for it to finish, or just kill the process...

 

[Yviena]

5 minutes ago, Miska said:

 

 

There is no way to cancel the initialization. You need to wait for it to finish, or just kill the process...

 

Oh ok I thought ESC did cancel it as it removed the initialisation progress bar.

[Miska]

40 minutes ago, Yviena said:

Oh ok I thought ESC did cancel it as it removed the initialisation progress bar.

 

Yes, that's the toolkit functionality. I didn't want to prevent closing it, but it's really just indication that there's background activity...

 

 

[dctom]

21 hours ago, Miska said:

 

Settings dialog is not related to a playlist. If it gets stuck at that point, likely reason is problem with one of the audio device drivers. When returning from the Settings dialog, the previous playlist is reloaded, which in turn means loading metadata for all the tracks on the playlist. That may take some time depending on speed of the computer, storage media and amount of free RAM.

 

But overall, there shouldn't be a reason to frequently open the Settings dialog. For normal use, I almost never need to open it.

 

 

thanks, have sorted it out now

[cat6man]

deleted

[Yviena]

On 12/2/2019 at 6:54 PM, Miska said:

 

Yes, that's the toolkit functionality. I didn't want to prevent closing it, but it's really just indication that there's background activity...

 

 

On another note have you noticed that modulator performance is erratic, and varying across HQPlayer restarts, for some reason modulator usage varies between 26-28%, and in some rare restarts it's at 22-24% instead...

[jimdukey]

How is that variation "Erratic?"

[Yviena]

1 hour ago, jimdukey said:

How is that variation "Erratic?"

Because it varies between each HQplayer restart sometimes it's constant 28% CPU usage, next restart it's around 25.5% constant, and sometimes on another restart it's running at 22.5% or in the rare case 19% CPU usage only.

There must be a reason CPU usage can vary by  as much as 8-9% on the same track, with no other software in the background running.

[Miska]

CPU frequencies vary from time to time, and so does load calculation time window vs process activity.

 

Load percentage is ratio between 100% and 0% load within some time window and that also depends on the particular core clock frequencies. Whenever CPU is executing something it is doing 100%, when not executing something it is doing 0%, at it's clock frequency which can vary independently.

 

HQPlayer pins only the heaviest threads, rest of the threads out of tens are allowed to run wherever the OS scheduler sees fit. These consume couple of % as well. In addition, OS itself is running bunch of processes and threads doing things like network and filesystem activity. Without such threads, HQPlayer wouldn't get any data in or out.

 

So those CPU load figures are rough estimates at best.

 

[pcmchild]

On 12/2/2019 at 4:57 PM, Miska said:

ASIO4ALL is not a real ASIO driver, it operates on top of KS/WASAPI and represent ASIO interface to applications. So it has combined limitations of both ASIO and WASAPI. So you could as well use WASAPI for input side too.

 

It shouldn't be resampling twice, just once. But it is likely Windows audio engine doing it. And WASAPI is likely falling back to Shared Mode, because two applications cannot simultaneously use the same hardware in Exclusive Mode.

 

Thanks again Jussi for all the explanations.

I was not aware that ASIO4ALL was not a real ASIO driver, but mainly and ASIO emulator layer over WASAPI. That explains most of the issues I have been having.

So I already uninstalled ASIO4ALL from my system. No need for it this way as WASAPI Exclusive does same job, and DAC accepts ASIO from output.

 

Meanwhile I found the ASIO driver from Realtek. It works...    .... but exactly as WASAPI.  Unlike ASIO4ALL that fakes rate auto-detection (0) by using the last rate used, with the Realtek driver, HQP accepts "Enter" of "0" rate, but does not accept play, just like with WASAPI.  So I guess the Realtek driver is also just an emulator layer over WASAPI.

 

Next step I  will get a relatively cheap (€50) PCI Creative sound card (with SPDIF input), to test if the Creative ASIO driver works with the auto-detect rate. The RME AIO card is too expensive at €500 for just the SPDIF input.

 

When you say "two applications cannot simultaneously use the same hardware in Exclusive Mode", do you mean even if different ports? I don't have two applications accessing the same port, MPC-BE uses SPDIF out and HQP uses SPDIF in. You mean that does not work in Exclusive because the two ports are on the same chip (Realtek)?

 

Although this auto-detect loopback process is requiring much time and effort, I still think it is worth it even if I don't fully succeed in the end. I am learning a lot in the process, both with your help and with my own research and test. And hopefully it may also help others who need loopback or input rate auto-detect.

[Miska]

5 minutes ago, pcmchild said:

Meanwhile I found the ASIO driver from Realtek. It works...    .... but exactly as WASAPI.  Unlike ASIO4ALL that fakes rate auto-detection (0) by using the last rate used, with the Realtek driver, HQP accepts "Enter" of "0" rate, but does not accept play, just like with WASAPI.  So I guess the Realtek driver is also just an emulator layer over WASAPI.

 

It is by no means mandatory to support the slave clocked feature of ASIO. The specification merely supports it and documents how it is ought to be used. But whether some hardware and driver actually support it is entirely different matter.

 

6 minutes ago, pcmchild said:

Next step I  will get a relatively cheap (€50) PCI Creative sound card (with SPDIF input), to test if the Creative ASIO driver works with the auto-detect rate. The RME AIO card is too expensive at €500 for just the SPDIF input.

 

I would say likelihood that any non-pro hardware would support it is fairly low. I don't have information how many pro-audio hardware and drivers support it. My guesstimate is something like 10% of the hardware on market. Reason is that studios rarely need such, since they are typically running everything at single rate and not really switching it ever. Or at least very rarely. If the hardware supports clock slaving and possibly thus has also WordClock input option, it is more likely that it would be supported.

 

I got it working with AIO card on Linux too, up to 96 kHz. So the hardware supports it fine, but the Linux driver has too many bugs and I don't have time to fix it. So the behavior was awkward, Toslink and AES work up to 96k (should work up to 192k) while coax works only at 44.1k and 48k (should also work up to 192k).

 

13 minutes ago, pcmchild said:

When you say "two applications cannot simultaneously use the same hardware in Exclusive Mode", do you mean even if different ports? I don't have two applications accessing the same port, MPC-BE uses SPDIF out and HQP uses SPDIF in. You mean that does not work in Exclusive because the two ports are on the same chip (Realtek)?

 

Yes, if they are on the same chip, it actually shouldn't work...

 

15 minutes ago, pcmchild said:

Although this auto-detect loopback process is requiring much time and effort, I still think it is worth it even if I don't fully succeed in the end.

 

I will also put up some info once I find time to test different pieces of hardware. For that reason I've moved the AIO cards to Windows machines. But I'm not even going to try anything else than pro-audio hardware. Expensive and time consuming exercise, especially due to all three OS platforms I support, I have already spent few thousand EUR on hardware that doesn't work for the purpose... Even though I've spent time reading their manuals before buying. But at least I have now one hardware that works flawlessly on Linux and another that works almost flawlessly on Linux too. Most of the testing on that front has been done using HQPlayer Embedded, because it was the first one to have input support.

 

[Outlaw]

HQPlayer 3 stopped working.Have not had this happen in about a year.Try to play something and the HQPlayer screen is just flashing.Hqplayer is putting a load on cpu as by task manager.I quit process and start again same thing happens.Last time this happed had to do fresh install of windows

[pcmchild]

13 minutes ago, Miska said:

If the hardware supports clock slaving and possibly thus has also WordClock input option, it is more likely that it would be supported.

 

I found this Sound Blaster Z that has optical input and ASIO 2.0 support:  https://en.creative.com/p/sound-blaster/sound-blaster-z

 

On their ASIO 2.0 page    https://support.creative.com/kb/ShowArticle.aspx?sid=84426

it mentions: "Sample Rate (word clock sync)" and also "Sample Position (time code sync)"

 

Looks like a good candidate for me to try, at €70.

 

Does ASIO 2.0 require any support from HQP, and if so, does HQP support it?

 

 

 

[Miska]

5 hours ago, pcmchild said:

Does ASIO 2.0 require any support from HQP, and if so, does HQP support it?

 

ASIO 2.x is already supported, probably 1.x wouldn't even work. These days "ASIO" == "ASIO 2.x".

 

[Miska]

7 hours ago, Outlaw said:

HQPlayer 3 stopped working.Have not had this happen in about a year.Try to play something and the HQPlayer screen is just flashing.Hqplayer is putting a load on cpu as by task manager.I quit process and start again same thing happens.Last time this happed had to do fresh install of windows

 

Did you change any settings? With some setting combinations it is normal to have 100% CPU load for 30+ seconds before playback starts, but the initialization spinner dialog should appear.

 

You could check the log file for errors or other hints what could be going wrong.

 

[Yviena]

@MiskaDoes Hqplayer support stereo convolution files, i get a error that the wav file is not mono.

[Miska]

9 minutes ago, Yviena said:

@MiskaDoes Hqplayer support stereo convolution files, i get a error that the wav file is not mono.

 

No, you need to split the files into per channel mono files. Stereo files are too restrictive and complicated, just too many assumptions.

 

[Yviena]

3 hours ago, Miska said:

 

No, you need to split the files into per channel mono files. Stereo files are too restrictive and complicated, just too many assumptions.

 

so would a REW mono file work then?

[Yviena]

Correct me if i'm wrong but i can leave gain compensation at 0, and use the volume control instead to prevent clipping correct?

[Outlaw]

14 hours ago, Miska said:

 

Did you change any settings? With some setting combinations it is normal to have 100% CPU load for 30+ seconds before playback starts, but the initialization spinner dialog should appear.

 

You could check the log file for errors or other hints what could be going wrong.

 

Didn't make any changes to settings.The HQPlayer screen just flashes and locks up.Did a system restore to fix.

[Miska]

3 hours ago, Yviena said:

Correct me if i'm wrong but i can leave gain compensation at 0, and use the volume control instead to prevent clipping correct?

 

Yes, since the clipping can only happen at the last stages before output, either in modulator or dither. If the level that reaches there is low enough there's no problem. HQPlayer itself doesn't let output do hard clipping, but instead at final stages it forces output level to comply with a soft level limiter, if that happens it is indicated by the Limited-counter. Limiter is designed to be as inaudible as possible, so the counter is important.

 

[Miska]

6 hours ago, Yviena said:

so would a REW mono file work then?

 

Yes, that should be fine, 32-bit integer or 32-/64-bit floating point.

 

[Yviena]

Anyone using ESS sabre dacs what DSD cutoff filter do you use?