Jump to content
IGNORED

HQ Player


Recommended Posts

Yes, I tried converting to different sample rates but still no sound. The weird thing is my DAC shows that it is receiving the music and the sample rate indicator changes matches what I set HQP to convert to. But I don't get any sound.

 

Ummm... Are you sure that the problem is not down the line after the dac?!

Try to make a small playlist with one 44.1 file and one DSF64 converting both to PCM 176.4. Do you hear sound for the 1st track and not for the 2nd track?

Link to comment
That's strange. I was sure the Mutec 3+ accepts DoP and native DSF files. I know that the Mutec converts DoP and DSF to pcm before reclocking but I just want to make sure I can get HQP to play native DSD since I am planning to get a DSD dac soon. The HQP website even says I need to dowoad some files for native DSD, I just don't know which ones.

 

If your DAC supports DSD through DoP, then in Settings/SDM set DoP. You should then be able to select SDM in the far right desktop drop-list.

If your DAC supports native DSD (non-DoP), you should install the following libasound2 and kernel packages from here, accordingly to your Linux version. After download, in Settings/SDM you should set "None" and be allowed to select SDM in the far right desktop drop-list.

Link to comment
Thank you but my problem is I don't know which files to download. If I go into the Trusty folder I see so many different files. It looks like many are just different versions of the same file but still i am not sure which ones to install. That's what I need help with.

I am not a Linux expert. However, this should be your list:

 

alsa-lib_1.0.27.2.orig.tar.bz2

 

------------------------

libasound2-data_1.0.27.2-3.1jl2

libasound2-dbg_1.0.27.2-3.1jl2

libasound2-dev_1.0.27.2-3.1jl2

libasound2-udeb_1.0.27.2-3.1jl2

libasound2_1.0.27.2-3.1jl2

libgmpris-dbg_2.2.1-4_amd64.deb

libgmpris-dev_2.2.1-4_amd64.deb

libgmpris_2.2.1-4

 

version amd64 or i386 it depends if you have 64 or 32bit OS

DL the ones in bold perhaps the other ones are DLed automatically

------------------------

Linux-headers

Linux-image

Linux-tools

 

DL all in version 4.0.2-35 low latency

 

I doubt you need linux-lts-willy and linux-cloud-tools. You could DL them later, if it does not recognize DSD native.

Link to comment

For those who want to try 3.14 beta1 for Windows...

 

I reluctantly installed it.

At launch I got the following error message:

 

d10_error.png

 

I need to reinstall a Visual C++ library

How to fix the ?api-ms-win-crt-runtime-l1-1.0.dll is missing? error for Delphi 10 Seattle | The curse of Dennis D. Spreen

At the link you will find the download link for Visual C++ runtime.

 

Once I reinstalled Visual C++ runtime, HQPlayer beta1 starts normally.

 

Apparently nothing has changed, but I am sure Miska will give us indication of changes in due time :)

Link to comment
When I launch it I automatically get the "failed to open" warning. I can't do anything to it. I've put in a message to [email protected] but have yet to hear back. It's basically inoperable at this point and would like to get a refund but I'm guessing I'm sol.

 

Firstly try to open HQP and playback without NAA.

If you get a "failed to open" during HQP statup, it probably refers to your device.

Can you enter HQP Setting menu and select an audio device? Also make sure that your audio device is not taken or in use by any other software application - that could be a reason for getting a failed message.

Link to comment
I am using i7 4790 Socket 1150 8G ram mini size PC Win 10 64bit, my dac T+A DSD 8, I can only do DSD 256 & 512 using SDM pack - set to NONE, with DoP , lots of stuttering with 256 & 512, when set to DoP, I can only get DSD128 running smoothly.

Nothing unusual in that.

As T+A DSD 8 is Amanero USB based, in Windows one can only do DSD128 with DoP (the same in Linux). That's way one is supposed to set SDM pack to "None" and use non-DoP DSD that allows up to DSD512.

Link to comment
I've been using HQ Player for 2 weeks now and I love it.

 

I am converting to DSD 128 and using DoP because seemingly my DAC won't support native DSD or a higher DoP rate.

 

I am getting clicks between every track. It sounds like a relay in the DAC turning off and on between tracks.

 

Is there an adjustment I can make to stop this annoying clicking sound?

 

What DAC is it?

Link to comment
I am trying to experiment with different filters and see what I like best with the Schiit Yggy dac which can go at most 192Khz. The main window is set to PCM. When "closed-form" filter is chosen, HQP plays perfectly with most of the sample rate, expect when the original file sample rate is 192KHz itself. It looks like HQP is trying to down sample the 192 to 176.4 in this case ? The HQP window shutters, as if it were trying to do something but unable.

 

If I set the filter to "none" or any of the poly-sync variants, then those files plays fine but I don't want to manually change it every time between sample rates. It also very awkward as I have a large playlist which consists of mixed sample rates, including pcm and dsd.

 

Anybody know how to fix this ?

 

Closed-form filter cannot automatically follow 44.1 e 48 kHz sample rate families. It has to be switched appropriately.

When you play a 192 kHz file, please be sure that your output setting is not on Auto but on 192.

Link to comment
Thanks but I did not understand what you mean by 192 instead of auto. Are you talking about the sample rate ?

 

On the main window, the 3rd column is shown as auto and I can't select anything other than auto from the drop down.

 

Yes, I am talking about the sample rate.

In the 3rd column drop down list you will be able to select something other than Auto once you have an album in the playlist window.

If you can't, your driver does not allow it.

Link to comment
Ok, but I can’t set anything other than auto. Its playing through Roon to the microRendu NAA.

 

Honestly, I can't figure out why can't HQP make an intelligent choice of not touching a 192Khz file when the sample rate selected is 192000 in the setting panel.

 

I just tried to playback a 192 kHz file. It seems that there is an odd behavior with closed-form filter. It is only possible to select (3rd column) an upsampling rate - higher than native. That is I can select (in my system) 384 kHz, but Auto does NOT work, instead it should be able to output at 192 kHz - same rate as native. Unless it is by design and Miska can explain it.

I hope Miska is reading us.

 

There is no problem with other filters, even with poly-sync-ext which should have a behavior similar to closed-form.

Link to comment
I just tested it and in my system, this doesn't work either. Even if you select 384, I can't select anything other than auto.

In my case with closed-form I am given the option to upsample a 192 file to 384.

Strange that you don't, once a file is in the playlist.

 

I had sent a mail to [email protected] this afternoon but yet to receive any reply.

It's Sunday in Finland too ;)

 

Yes, I tested most of the poly-sync variant and they seem to work fine.

 

My simple question is - when I am up-sampling and irrespective of what filters I select, HQP need NOT mangle with the file if the max sampling rate and the file's sampling rate are the same. ...

This is a different question - it is a feature you would like to see implemented.

If you do not wish to upsample, you choose NONE as filter.

Link to comment

Miska,

 

a friend of mine using Linux (HQP v3.13) has a problem with this DAC.

The device plays correctly with other players, but HQP doesn't. Somehow it does not recognizes the device.

This is the log:

* 2016/06/26 01:42:20 Starting...

2016/06/26 01:42:20 Signalyst HQPlayer Desktop v3.13.3

2016/06/26 01:42:20 Engine selected:

* 2016/06/26 01:42:20 Control server started

2016/06/26 01:42:24 libDSP version 17.1.0

2016/06/26 01:42:24 Audio engine: alsa

2016/06/26 01:42:24 asoundlib version: 1.0.28

- 2016/06/26 01:42:24 ALSA backend uninitialized

2016/06/26 01:42:24 Set channels: 2 (2)

2016/06/26 01:42:24 DAC bits: 32

2016/06/26 01:42:24 ALSA device: hw:0,0

2016/06/26 01:42:24 ALSA access mode: 3

2016/06/26 01:42:24 ALSA PCM format: S32_LE

2016/06/26 01:42:24 ALSA PCM bits: 32

2016/06/26 01:42:24 ALSA PCM physical width: 32

2016/06/26 01:42:24 ALSA PCM rates: 44100 - 384000

2016/06/26 01:42:24 ALSA DSD format:

! 2016/06/26 01:42:24 createEngine(): clHQPlayerEngine::Initialize(): clALSAMiniEngine::Initialize(): snd_pcm_format_physical_width(): Invalid argument

& 2016/06/26 01:42:27 Playlist save: /home/paolo/.hqplayer/current.m3u8

- 2016/06/26 01:42:27 ALSA backend uninitialized

2016/06/26 01:42:27 asoundlib version: 1.0.28

2016/06/26 01:42:27 Found ALSA device: hw:0,0 - DIYINHK USB Audio 2.0: USB Audio

- 2016/06/26 01:42:32 ALSA backend uninitialized

2016/06/26 01:42:33 libDSP version 17.1.0

2016/06/26 01:42:33 Audio engine: alsa

2016/06/26 01:42:33 asoundlib version: 1.0.28

- 2016/06/26 01:42:33 ALSA backend uninitialized

2016/06/26 01:42:33 Set channels: 2 (2)

2016/06/26 01:42:33 DAC bits: 32

2016/06/26 01:42:33 ALSA device: hw:0,0

2016/06/26 01:42:33 ALSA access mode: 3

2016/06/26 01:42:33 ALSA PCM format: S32_LE

2016/06/26 01:42:33 ALSA PCM bits: 32

2016/06/26 01:42:33 ALSA PCM physical width: 32

2016/06/26 01:42:33 ALSA PCM rates: 44100 - 384000

2016/06/26 01:42:33 ALSA DSD format:

! 2016/06/26 01:42:33 clMainWindow::settingsTriggered(): clMainWindow::reinitEngine(): clHQPlayerEngine::Initialize(): clALSAMiniEngine::Initialize(): snd_pcm_format_physical_width(): Invalid argument

# 2016/06/26 01:42:36 clMainWindow::setTransport(): clHQPlayerEngine::SetTransport(): failed

& 2016/06/26 01:42:42 Playlist clear

 

Possibly HQP uses some parameters that don't go well with the device. Apparently, they seem OK:

$ alsacap

*** Scanning for playback devices ***

Card 0, ID `D20', name `DIYINHK USB Audio 2.0'

Device 0, ID `USB Audio', name `USB Audio', 1 subdevices (1 available)

2 channels, sampling rate 44100..384000 Hz

Sample formats: S16_LE, S32_LE, SPECIAL

Subdevice 0, name `subdevice #0'

 

Any suggestions? Bug?

 

BTW, the same behavior is confirmed on a different PC.

Link to comment
Too old kernel/libasound2 lacking native DSD support...

 

Kernel is this:

Linux version 4.6.0-0.bpo.1-amd64 ([email protected]) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.6.1-1~bpo8+1 (2016-06-14)

...but installing libasound up to date it works:

$ dpkg -l|grep -i libasound

ii libasound2:amd64 1.0.28-1jl1 amd64 shared library for ALSA applications

ii libasound2:i386 1.0.28-1jl1 i386 shared library for ALSA applications

ii libasound2-data 1.0.28-1jl1 all Configuration files and profiles for ALSA drivers

 

Shouldn't HQP be able to work anyway (like other players) and simply disable DSD playback?

Link to comment
  • 2 weeks later...
can someonen tell me how to set (none, none, auto, auto) in hqplayer desktop? i assume that is the setting for no upsampling or signal processing at all, just rendering at the native resolution. i did some tests this afternoon and want to make sure i set things up properly.

 

i have turned off filter and dither and it appears that the native resolution is being passed through.

is that correct?

 

i want to report my results but need to make sure i did the test correctly (quick peak: NAA mode was amazing) before i draw conclusions.

 

my interest was in comparing minimserver-hqplayer-NAA mode with minimserver-MPD mode on the uRendu, so basically moving the renderer off of the uRendu with zero signal processing.

 

Yes, it is correct. Although I would personally still use some dither for 14/44.1 files.

Link to comment
Juergen's Lintweaker github seems to have gone a bit quiet about any Amanero Linux work lately (last real update was Jussi's comment 20 days ago that RC3 doesn't work). Does anyone know any updates or where the ball is right now? For those wondering why I ask here, this affects many dacs' ability to do raw/direct/native DSD (like accepting DSD512 upsampling from HQP) in Linux.

 

I spoke to Domenico of Amanero last week, before he went to London for work. I've been in touch with him every week for the last few months.

He wants to be sure to release a final working firmware, at the same time he is busy for the release of a new multi-channel card.

It was his intention to get in touch with Miska/Jussi for testing the firmware. I don't know if he did. Perhaps Jussi can pitch in...

Anyhow, the firmware itself is for sure near completion.

Link to comment
I think no digital (coaxial or optical) can send bitrate more then 24/192 or DOP 64

I think it's the bottle neck with the technology

 

I have not come across any component (dac or USB to spidif or i2s to spidif ) then can do more then 24/192

 

MSB Technologies supports 128x for all their digital inputs (including S/PDIF).

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...