HQ Player

[aps]

There is manual included in every installation package. So version 3.12 comes with manual version 3.12. On Windows there's a shortcut created in the Start-menu for the manual. You can search for "HQPlayer" in the start menu. On Mac the manual is part of the DMG since 3.13, previously it was in the surrounding ZIP file. On Linux there is also start-menu entry created for the manual.

 

For your case matrix should look like this:

[table=width: 500]

[tr]

[td]Src[/td]

[td]Gain[/td]

[td]Mix[/td]

[/tr]

[tr]

[td]1[/td]

[td]0[/td]

[td]1[/td]

[/tr]

[tr]

[td]2[/td]

[td]0[/td]

[td]2[/td]

[/tr]

[tr]

[td]1[/td]

[td]-6[/td]

[td]3[/td]

[/tr]

[tr]

[td]2[/td]

[td]-6[/td]

[td]3[/td]

[/tr]

[/table]

 

Miska

 

Thanks. That's great - and I've set-up the matrix to mix channels 1 & 2 with reduced gain for the 3 subwoofer channels (3-5). The filters have been set-up in the Convolution Screen. My question, now, is that whilst the Convolution Screen shows filters against the channels (1-5) the Matrix Screen has convolution against the first 5 items rather than the full list. I'm guessing that this isn't an issue but rather an artefact of the design of the Matrix Screen. Is this correct or am I missing something (again)?

[jhwalker]

Jussi, DSD>PCM drops constantly using Roon build 99. And any combination under SDM drops out also during playback I have tried every possible combination. The only setting that plays without any major dropout issue is when I use PCM only.

 

2015 iMac>Pulse Infinity>roon>HQP 3.13beta2

 

I'm not having this problem, but have to ask: why are you converting DSD > PCM for playback on the Pulse Infinity? It supports DSD via DoP.

 

You're certainly welcome to do so, just wondering why.

[EdmontonCanuck]

Please excuse me my ignorance, but what is Pulse Infinity?

 

It's an Indiegogo crowd-funded DSD DAC built by LH Labs.

[digitalzed]

I'm not having this problem, but have to ask: why are you converting DSD > PCM for playback on the Pulse Infinity? It supports DSD via DoP.

 

You're certainly welcome to do so, just wondering why.

I understand why that seems (is) strange. Something as a beta tester for Roon I was trying.

[Le Concombre Masqué]

offload seems to work remarkably well (cuts cpu usage by a factor of 2, no issue, great sound with closed form) ; what bothers me is the need to uncheck cuda, quit, relaunch, in order to use poly sinc, (which I need with all n48 files), this being a bug IMO.

If your GPU is not the very latest, it may not help, at least with all supported algorithms. IOW, it is not necessarily faster than your CPU even on the specific tasks it is assigned on. If GPU is significantly slower than the CPU then it is possible that the offload just harms instead of helping.

[aps]

Miska

 

Thanks. That's great - and I've set-up the matrix to mix channels 1 & 2 with reduced gain for the 3 subwoofer channels (3-5). The filters have been set-up in the Convolution Screen. My question, now, is that whilst the Convolution Screen shows filters against the channels (1-5) the Matrix Screen has convolution against the first 5 items rather than the full list. I'm guessing that this isn't an issue but rather an artefact of the design of the Matrix Screen. Is this correct or am I missing something (again)?

 

Miska

 

I've done some further investigation and resolved the issue. The solution, for other interested parties, was to fill in the filter text under each of the rows in the Matrix Screen. I guess, ideally, the filter from the convolution screen would populate each row in the matrix screen with the same mix channel but the above solution seems to work

[bogi]

I also recommend just taking the original DXD file (not the MQA variant) and playing that as upsampled to highest rate DSD your DAC can support for comparison.

 

Currently I'm connected with mobile internet and restricted data plan, I will download the DXD file next week.

 

You could also try out the 96k file and ordinary RedBook played through the poly-sinc-mqa filter and see how it sounds, although the poly-sinc-mqa is not intended to be used that way. But for comparison.

 

I preferred the poly-sinc version. The mqa alternative IMO added some brightness to the sound and something unnatural - I think some form of distortion, which maybe also caused that I perceived slightly lower dynamic impact.

 

I repeated once again my comparison of 24/96 file (with poly-sinc) and real MQA file (with poly-sinc-mqa) from yesterday. I would say MQA something improved - timbre of instruments, more involving presentation, but also maybe lowered impact of dynamic changes. So I'm not sure if MQA is pure win. Overall I liked listening to the MQA file more because of more involving presentation, something in direction like when you switch from Sabre based DAC to iFi DAC, but I think that I also lost something.

 

Comparing poly-sinc-mqa in both experiments: With MQA file I didn't have that unnatural feeling like with the ordinary FLAC (not MQA) file, but in both cases switching from poly-sinc to poly-sinc-mqa IMO added some brightness and also lowered perceived dynamic impact. Maybe it added some distortion in both cases ... but that's only my guess. I'm not a measurement device.

 

All I wrote are only my subjective opinions related to me and my DAC, so please take it this way.

[bogi]

Miska, I found yet one bug. It occurs when I switch from 24/96 file to MQA file within a playlist.

 

I am listening a passage of PCM 24/96 file as DSD 6.1MHz and pressing the stop button. Then I wish to listen the MQA file. I am switching the filter to poly-sinc-mqa. But then I cannot change bitrate to 44.1k based DSD rates for example 5.6MHz. It seems it remembers, that the last file played was PCM on 48k base (and not 44.1k base) and it offers me only 3.1 and 6.1 MHz DSD rates. So I let the 6.1MHz setting and attempt to play the MQA file, but it doesn't start. It seems 48k based bitrates are not allowed for poly-sinc-mqa, but I cannot switch to 44.1k based one.

 

I have to switch the filter back to poly-sinc. Then I can switch the DSD bitrate to 5.6k. I need to play a passage of the MQA file and stop playback. Then after switching from poly-sinc to poly-sinc-mqa bitrate stays on 5.6k and I can choose from 44.1k based bitrates. It seems it really remembers if the last played PCM file is 44.1k or 48k based.

 

The solution could be that the bitrate could switch automatically to 44.1k base if it is required for the MQA file to be played.

[zorntel]

Is the system (1) running OS X? If that is the case, it will always require DoP because OS X doesn't have support for raw DSD (except exaSound DACs with ASIO, but that is not supported by networkaudiod).

 

If in system (2) the NAA is running fresh enough Linux/networkaudiod (I assume it is), then it works just fine without DoP to iDSD.

 

I think in your case system (1) is limited to DoP by both OS and the DAC.

 

Both systems are using OSX...but only the one with the IFI dac will go without DoP. I've switched out the Cubox-i with your NAA linux build and the Sonicorbiter and that doesn't make any difference. So I'm assuming that the issue here is the Auralic requiring DoP, while the IFI apparently doesn't? Do you know if the Mytek DACs will run without DoP like the IFI? I have a new Brooklyn on order. I believe that uses the same chip as the Auralic...but obviously the chip isn't the issue as to whether DoP is required or not.

[KMan]

I have gone back to 3.12.0. 3.13.0b2 just will not work with DSD->PCM directly or through Roon and for all Dacs. This is unfortunate as Hugo TT seems to sound better with PCM 384K than when fed DSD128. With 3.12.0 and Roon 99, DSD->PCM still des not work and DSD stalls after few tracks.

[Miska]

Both systems are using OSX...but only the one with the IFI dac will go without DoP.

 

When you are using NAA, the system running HQPlayer doesn't matter. What matters is the system running NAA, which in case of Sonore device is Linux...

 

I've switched out the Cubox-i with your NAA linux build and the Sonicorbiter and that doesn't make any difference. So I'm assuming that the issue here is the Auralic requiring DoP, while the IFI apparently doesn't?

 

Yes, that's the case. But in addition if you run networkaudiod on Mac OS X, you are anyway limited to DoP, even with iFi.

 

Do you know if the Mytek DACs will run without DoP like the IFI? I have a new Brooklyn on order.

 

No, not at the moment. We'll see if that support appears, but since (AFAIK) Brooklyn uses XMOS for USB, it should be matter of implementing that support. It could be even very simple to get that supported, but I don't have Brooklyn myself to test with.

 

I believe that uses the same chip as the Auralic...but obviously the chip isn't the issue as to whether DoP is required or not.

 

What matters is how the USB is implemented... That support needs to be before the DAC chip.

[Miska]

I have gone back to 3.12.0. 3.13.0b2 just will not work with DSD->PCM directly or through Roon and for all Dacs. This is unfortunate as Hugo TT seems to sound better with PCM 384K than when fed DSD128. With 3.12.0 and Roon 99, DSD->PCM still des not work and DSD stalls after few tracks.

 

I've now found and fixed this initialization bug for next release. Meanwhile as workaround, if you set "Conversion type" to "traditional" in DSDIFF/DSF Settings dialog, it works...

 

I noticed this stall also once during my testing yesterday. Seems like Roon stops sending data to HQPlayer for some reason. But I'm not completely sure yet what is going on. It is quite hard to debug because at least for me it needed about half an hour of playback before that happened.

[Miska]

Miska, I found yet one bug. It occurs when I switch from 24/96 file to MQA file within a playlist.

 

I am listening a passage of PCM 24/96 file as DSD 6.1MHz and pressing the stop button. Then I wish to listen the MQA file. I am switching the filter to poly-sinc-mqa. But then I cannot change bitrate to 44.1k based DSD rates for example 5.6MHz.

 

This works as intended, poly-sinc-mqa can do only simple rate multiples, not fractional rates due to filter properties. poly-sinc-ext has the same limitation.

[Miska]

I've done some further investigation and resolved the issue. The solution, for other interested parties, was to fill in the filter text under each of the rows in the Matrix Screen. I guess, ideally, the filter from the convolution screen would populate each row in the matrix screen with the same mix channel but the above solution seems to work

 

The convolution setup and matrix are sort of mutually exclusive, but they share the filter setup. So you can also configure everything in matrix setup, but selecting the filter files may be a bit more convenient in convolution dialog. Convolution setup dialog covers the first 8 virtual channels of matrix.

 

I will try to clarify this in the manual.

[bogi]

This works as intended, poly-sinc-mqa can do only simple rate multiples, not fractional rates due to filter properties. poly-sinc-ext has the same limitation.

 

That I understand and I have no objections against that! Could you please read my previous post once again more carefully?

 

Shortly, I played 24/96 PCM track and stopped it. Then I was unable manually to set 44.1k based DSD rate to play MQA track in the playlist. I had a track in my playlist but no setting in the main window allowed to play it. The main window allowed to set only 48k base DSD rates, but my track in the playlist was 44.1k based MQA and there was no way to play it with poly-sinc-mqa. Please once again, read more carefully my previous post.

 

Other findings resulting from the same issue:

 

A)

poly-sinc-mqa ASDM7 6144000 SDM(DSD)

Playlist with 2 tracks

1. track 24/96

2. track MQA 24/44.1

As soon as the 1st track finishes, the 2nd track refuses to start.

 

B)

poly-sinc-mqa ASDM7 5644880 SDM(DSD)

Playlist with 2 tracks

1. track MQA 24/44.1

2. track 24/96

As soon as the 1st track finishes, the 2nd track refuses to start.

[Miska]

A)

poly-sinc-mqa ASDM7 6144000 SDM(DSD)

Playlist with 2 tracks

1. track 24/96

2. track MQA 24/44.1

As soon as the 1st track finishes, the 2nd track refuses to start.

 

B)

poly-sinc-mqa ASDM7 5644880 SDM(DSD)

Playlist with 2 tracks

1. track MQA 24/44.1

2. track 24/96

As soon as the 1st track finishes, the 2nd track refuses to start.

 

OK, thanks, my misunderstanding!

 

This is also problematic case with previous versions. Track 1 defines "transport rate" since the system expects first track to be played being the first track on the transport. Thus the available selections depend on first track.

 

There is also internal support for "queued" items on playlist, this was created for HQPlayer Embedded and is also used by external control applications. These tracks automatically disappear from the playlist once playback of the track completes (reaches end, or "next" is requested). Thus the second track becomes the first one. So it is sort of track FIFO, you add to the end and things disappear from the beginning as they are completed.

 

This could be also enabled for drag-and-drop type of use by adding a toolbar toggle button if it seems useful.

[Miska]

My question, now, is that whilst the Convolution Screen shows filters against the channels (1-5) the Matrix Screen has convolution against the first 5 items rather than the full list. I'm guessing that this isn't an issue but rather an artefact of the design of the Matrix Screen. Is this correct or am I missing something (again)?

 

Channel mapping follows the ITU/EBU standard and this is reflected between the two dialogs:

1. Front Left
   
2. Front Right
   
3. Front Center
   
4. LFE
   
5. Rear Left
   
6. Right Right
   
7. Side Left
   
8. Side Right
   

[dean70]

OK, thanks, my misunderstanding!

 

This is also problematic case with previous versions. Track 1 defines "transport rate" since the system expects first track to be played being the first track on the transport. Thus the available selections depend on first track.

 

There is also internal support for "queued" items on playlist, this was created for HQPlayer Embedded and is also used by external control applications. These tracks automatically disappear from the playlist once playback of the track completes (reaches end, or "next" is requested). Thus the second track becomes the first one. So it is sort of track FIFO, you add to the end and things disappear from the beginning as they are completed.

 

This could be also enabled for drag-and-drop type of use by adding a toolbar toggle button if it seems useful.

 

I have seen this myself when switching between sample rate families (not in the same playlist). Usually trying a couple of times by removing/re-adding the playlist with the new sample rate items will correct the issue.

[bogi]

OK, thanks, my misunderstanding!

 

This is also problematic case with previous versions. Track 1 defines "transport rate" since the system expects first track to be played being the first track on the transport. Thus the available selections depend on first track.

 

There is also internal support for "queued" items on playlist, this was created for HQPlayer Embedded and is also used by external control applications. These tracks automatically disappear from the playlist once playback of the track completes (reaches end, or "next" is requested). Thus the second track becomes the first one. So it is sort of track FIFO, you add to the end and things disappear from the beginning as they are completed.

 

This could be also enabled for drag-and-drop type of use by adding a toolbar toggle button if it seems useful.

 

With the FIFO scenario you explained I would loose the playlist content, so I would not be able to repeat listening to the playlist tracks without constructing the playlist again. My playlists typically don't exist as files and I am constructing them dynamically. The result exists only in HQPlayer. When I am listening to a new music material, I am typically repeating the same playlist some time. Similarly, when I am testing some settings or hardware, I also wish to play the same passages from the same tracks repeatedly. Therefore my suggestion how to solve the issue would be a little different.

 

Imagine you have 6144000 set as max. SDM bitrate in the Settings dialog. A playlist with some tracks appears in the main window. As soon as you click OK in the Settings dialog, the SDM bitrate in the main window adapts to max. possible value below or equal to 6144000 - depending on filter used and original bitrate of the track file. So it need not to be necessarily 6144000. I would like the same evaluation to be run before each next playlist track to be played. This behavior could be restricted to playlist mode (for album mode it wouldn't have much sense).

 

So HQPlayer would adapt bitrate of each playlist track to max. playable bitrate against the limit from the Settings dialog. That's important for filters like CF and poly-sinc-mqa, which can do only "integer multiple of sample rate".

[Miska]

Imagine you have 6144000 set as max. SDM bitrate in the Settings dialog. A playlist with some tracks appears in the main window. As soon as you click OK in the Settings dialog, the SDM bitrate in the main window adapts to max. possible value below or equal to 6144000 - depending on filter used and original bitrate of the track file. So it need not to be necessarily 6144000. I would like the same evaluation to be run before each next playlist track to be played. This behavior could be restricted to playlist mode (for album mode it wouldn't have much sense).

 

So HQPlayer would adapt bitrate of each playlist track to max. playable bitrate against the limit from the Settings dialog. That's important for filters like CF and poly-sinc-mqa, which can do only "integer multiple of sample rate".

 

I have now added "Auto" as first item to sample rate and mode drop-lists in main window. Down side with the current GUI design is that you don't see what ends up being selected inside the engine. But it is less issue for those DACs/NAAs that have front panel display.

[craighartley]

Imagine you have 6144000 set as max. SDM bitrate in the Settings dialog. A playlist with some tracks appears in the main window. As soon as you click OK in the Settings dialog, the SDM bitrate in the main window adapts to max. possible value below or equal to 6144000 - depending on filter used and original bitrate of the track file. So it need not to be necessarily 6144000. I would like the same evaluation to be run before each next playlist track to be played. This behavior could be restricted to playlist mode (for album mode it wouldn't have much sense).

It would make great sense if you were choosing the albums in Roon where you don't have access to HQPlayer controls.

[craighartley]

I have now added "Auto" as first item to sample rate and mode drop-lists in main window. Down side with the current GUI design is that you don't see what ends up being selected inside the engine. But it is less issue for those DACs/NAAs that have front panel display.

 

That's a wonderful addition.

[Chodi]

I have now added "Auto" as first item to sample rate and mode drop-lists in main window. Down side with the current GUI design is that you don't see what ends up being selected inside the engine. But it is less issue for those DACs/NAAs that have front panel display.

 

I have 3.13 beta 2 installed on Windows and I don't see this auto setting in the drop down list? Is there a newer beta 3.13 b3?

[bibo01]

I have 3.13 beta 2 installed on Windows and I don't see this auto setting in the drop down list? Is there a newer beta 3.13 b3?

 

Chiodi, you are ahead of the game!

...probably in next beta or final version.

[dean70]

Are there any plans to make the Invert Phase & Repeat single/all functions accessible from the API?