HQ Player

[Miska]

- dB indicator should always be visible, not disappear after a few seconds

- volume know should keep dimensions, possibly with min e max values next to it

- when one controls at minimum level, it jumps too easily to max (very dangerous)

 

This is probably material for 4.x series. The current control is a toolkit component and has some limitations. The volume control roller in full-screen mode is my implementation.

 

- keyboard control should require two separate keys for volume, without sharing keys with changing track.

 

I'm not sure what you mean by sharing keys? Key bindings are for different key codes entirely.

[Miska]

I noticed there is an update for HQPlayer from 3.11 to 3.12, do I have to download the whole application again and run a setup or is there a way to update it from with in the application?

 

Yes, you just download the application and reinstall...

 

Is there a document stating the enhancements made per version?

 

Front page of the website... (also on Facebook group and Twitter, although description on Twitter is of course shortened)

[KMan]

OOPS poly sinc stutters when going 64 too just not so immediate... cpu load up to 50%

 

btw who has 3.12 working on OS X ? Any clue ?

 

Streaming through Roon. I am running 3.12 on Yosemite, MBP '14 (cuda enabled). I use poly-sinc-*-2s, OS on SSD, HQplayer on RAM Disk, NAA on Audiolinux. Stutters at DSD256 or above but In most cases It works if I keep HQplayer in full screen and in the foreground and I am not running any other app. I feel it may be a OS prioritization issue. If HQplayer is in the background, stuttering starts.

 

I also tried to use renice and elevated the priority of HQplayer to real-time, it did not help much, which again makes me think this could be a network issue. It could also be related to NAA (maybe network i/o priority?). I am going to experiment with that tonight without NAA. CPU usage is typically around 150% for Redbook -> DSD256, but it could stutter at DSD128 with 100% CPU usage if not in the foreground and another app is open.

 

It is defenitely not a CPU resource issue. On the same MBR, I have a VM running windows 7.1 (with all 4 cores made available to the VM + 12GB RAM made available). HQplayer can do Redbook -> poly-sinc-*-2s up to DSD512 with no stuttering! (CUDA cannot be made available to VMs so only pipeline SDM is available). CPU hits 340%. In fact I prefer the VM on MBP as it is very stable with no stuttering.

[bibo01]

- keyboard control should require two separate keys for volume, without sharing keys with changing track.

 

I'm not sure what you mean by sharing keys? Key bindings are for different key codes entirely.

The 2 pairs of arrow keys on the keyboard are both used for volume and change track, it depends if one with the cursor has activated volume or track change. Since one alternates almost always between the two operations, when you go to change volume you actually change track. A simple solution would be to have two fixed keys to change track and especially another two fixed keys for volume.

To change track the cursor is fine, but fine volume adjustment can only be done through keyboard keys. So the implementation must be functional.

[Le Concombre Masqué]

" In fact I prefer the VM on MBP as it is very stable with no stuttering".... not exactly a report that 3.12 is flawless on os X... straight from coreaudio poly sinc stutters too here...

Streaming through Roon. I am running 3.12 on Yosemite, MBP '14 (cuda enabled). I use poly-sinc-*-2s, OS on SSD, HQplayer on RAM Disk, NAA on Audiolinux. Stutters at DSD256 or above but In most cases It works if I keep HQplayer in full screen and in the foreground and I am not running any other app. I feel it may be a OS prioritization issue. If HQplayer is in the background, stuttering starts.

 

I also tried to use renice and elevated the priority of HQplayer to real-time, it did not help much, which again makes me think this could be a network issue. It could also be related to NAA (maybe network i/o priority?). I am going to experiment with that tonight without NAA. CPU usage is typically around 150% for Redbook -> DSD256, but it could stutter at DSD128 with 100% CPU usage if not in the foreground and another app is open.

 

It is defenitely not a CPU resource issue. On the same MBR, I have a VM running windows 7.1 (with all 4 cores made available to the VM + 12GB RAM made available). HQplayer can do Redbook -> poly-sinc-*-2s up to DSD512 with no stuttering! (CUDA cannot be made available to VMs so only pipeline SDM is available). CPU hits 340%. In fact I prefer the VM on MBP as it is very stable with no stuttering.

[Miska]

btw who has 3.12 working on OS X ? Any clue ?

 

Works for me on both of my Macs to DSD128:

 

Mac Mini (Mid 2011), Yosemite, TEAC UD-501 (poly-sinc, ASDM7, PipelineSDM disabled since this is dual-core)

iMac 27" (Late 2013), El Capitan, Mytek Stereo192-DSD (poly-sinc, ASDM7, PipelineSDM enabled since this is quad-core)

 

Unmodified OS, also running anti-virus software on both.

 

My spouse has MacBook Air, I can try on that one too.

[Le Concombre Masqué]

yes thank you ; El Capitan is unmodified on my mid 12 MBPr 's SSD and it doesn't work with poly sinc while I believe I tried any combination

Works for me on both of my Macs to DSD128:

 

Mac Mini (Mid 2011), Yosemite, TEAC UD-501 (poly-sinc, ASDM7, PipelineSDM disabled since this is dual-core)

iMac 27" (Late 2013), El Capitan, Mytek Stereo192-DSD (poly-sinc, ASDM7, PipelineSDM enabled since this is quad-core)

 

Unmodified OS, also running anti-virus software on both.

 

My spouse has MacBook Air, I can try on that one too.

[Miska]

The 2 pairs of arrow keys on the keyboard are both used for volume and change track, it depends if one with the cursor has activated volume or track change. Since one alternates almost always between the two operations, when you go to change volume you actually change track. A simple solution would be to have two fixed keys to change track and especially another two fixed keys for volume.

To change track the cursor is fine, but fine volume adjustment can only be done through keyboard keys. So the implementation must be functional.

 

I'm not sure what you are talking about...

 

I have tested the functionality on couple of multimedia keyboards and it has been working fine. Play/Stop/Next/Prev/Fwd/Rew buttons act on tracks and VolumeUp/VolumeDown/Mute buttons act on volume. I've tested this on both Logitech and Microsoft keyboards that have multimedia-keys. Also Apple IR-remote works correctly on Win8.1 installed with BootCamp. Remote controls from other vendors are likely to work correctly too.

[Miska]

yes thank you ; El Capitan is unmodified on my mid 12 MBPr 's SSD and it doesn't work with poly sinc while I believe I tried any combination

 

Now I tried also on this third machine, using iFi iDSD Nano and playing FLAC content over WiFi from a file server (smb:// mount). No problems... So I don't really know what is going wrong for you...

 

[Hammer]

HQPlayer needs normal environment because it has a GUI. But putting it to the startup folder and configuring Windows to auto-login at bootup works. I have one of my machines configured such way.

 

That works! Thanks for the tip! Can't wait to see what HQPlayer has in stored in 2016! Happy New Year!

[4est]

I find it interesting that some of the changes in 3.12 have dramatically reduced (essentially to zero) the initialization time of poly-sinc/dsd7/11.2MHz when CUDA offload is on, yet returns when CUDA offload is off. This computer does not have CUDA, but uses Intel HD400 graphics. I got excited and tried 22MHz and the initialization wait returned with a vengeance and stuttered horribly once play began.

 

Color me confused, but pleased that 3.12 is actually running on this machine as the beta did not. I received my 750ti card last night, and look forward to seeing how it performs.

[Le Concombre Masqué]

I deeply admire your work so please indulge this daring question : are you sure you're testing the very same build (december 23 23.55) that's on line ? You suggested to check app nap ; there's no prevent app nap box and sometimes it shows yes sometimes no... does not seem to relate with the stuttering but I gonna disable it system wide though...

Now I tried also on this third machine, using iFi iDSD Nano and playing FLAC content over WiFi from a file server (smb:// mount). No problems... So I don't really know what is going wrong for you...

 

[ATTACH=CONFIG]23048[/ATTACH]

[orgel]

So I'm using Roon 3.12 (in trial mode, at a friend's house) on Mac OS 10.8.4, and it appears that HQP is switching the left and right channels. Has anyone else noticed this happening? Is it operator error, or could there be an HQP bug causing this? Is there a way to switch the channels the other way?

 

--David

[madfloyd]

I'm using Roon & HQPlayer together and am experiencing a loss of connection between Roon and HQPlayer. This happens at the end of a song and I have to shutdown and restart HQPlayer before I can play music again.

 

Anyone else experiencing this? I'm guessing it's a HQPlayer bug since restarting the HQPlayer app fixes it.

[Le Concombre Masqué]

no such thing here. Can only upsample to DSD through closed form but get gorgeous sound and no channel inversion

So I'm using Roon 3.12 (in trial mode, at a friend's house) on Mac OS 10.8.4, and it appears that HQP is switching the left and right channels. Has anyone else noticed this happening? Is it operator error, or could there be an HQP bug causing this? Is there a way to switch the channels the other way?

 

--David

[Samuel T Cogley]

OOPS poly sinc stutters when going 64 too just not so immediate... cpu load up to 50%

 

btw who has 3.12 working on OS X ? Any clue ?

 

Hope this helps...

 

I'm using 3.12 with Yosemite on a Mac Pro 6,1 (quad core) and it works flawlessly with all flavors of poly-sinc*-2, poly-sinc-ext, and closed-form at DSD256 to an iDSD Micro.

 

I don't know if this is an issue, but I'm unable to use any of the non "-2" poly-sinc filters (with "Pipeline SDM" enabled or disabled). HQPlayer just sits there when I attempt to start playback (EDIT: I was impatient, playback starts eventually).

 

 

EDIT: I experimented a bit with "poly-sinc" (not the "-2s" version).

 

With "Pipeline SDM" both on and off

 

All tests with ASDM7

 

DSD256: Takes 30 seconds or more to start, solid stuttering

DSD128: Takes 20 seconds to start, sort of plays without stuttering but is unstable and the slightest additional load on the CPU will cause stuttering and clicks. The "top" command here shows CPU usage of HQPlayer is 215% (using over two cores constantly)

 

Using "poly-sinc-2s", DSD256 is solid on this Mac. The "top" command shows CPU usage of HQPlayer to be 145% (using less than 1.5 cores).

[Samuel T Cogley]

I'm using Roon & HQPlayer together and am experiencing a loss of connection between Roon and HQPlayer. This happens at the end of a song and I have to shutdown and restart HQPlayer before I can play music again.

 

Anyone else experiencing this? I'm guessing it's a HQPlayer bug since restarting the HQPlayer app fixes it.

 

Is the audio interface you're pointing HQPlayer at disabled in Roon?

[tedevang]

You can do EQ in HQPlayer using the provided convolution engine. You can use for example RoomEq Wizard to create a filter with multiple parametric EQs. Acourate is powerful application that can be also used to create many different kinds of filters.

 

Support for external plugins is not in the plans. So far plugins like AU and VST support only PCM, while HQPlayer provides equivalent functionality for both PCM and DSD. Thus such plugins would add artificial limitations to the processing chain.

 

I tried the convolution engine and the results don't match what I was expecting. Should I exaggerate the values in Room EQ Wizard even more than I have them below? With the following values I don't get the bump around 4K I was expecting. In Audirvana I use Voxengo Gliss and I took the values I use there as a basis for the Room EQ filters and am only getting minor results so I exaggerated them but still the audio is kind of veiled.

 

Room EQ V5.14

Dated: Dec 31, 2015 2:05:26 PM

 

 

Notes:

 

 

Equaliser: Generic

No measurement

Filter 1: ON LS Fc 59.8 Hz Gain 10.0 dB

Filter 2: ON PK Fc 132 Hz Gain -8.0 dB Q 14.14

Filter 3: ON PK Fc 840 Hz Gain 2.0 dB Q 10.61

Filter 4: ON PK Fc 4,220 Hz Gain 16.0 dB Q 10.61

Filter 5: ON HS Fc 11,625 Hz Gain 12.0 dB

Filter 6: OFF None

Filter 7: OFF None

Filter 8: OFF None

Filter 9: OFF None

Filter 10: OFF None

Filter 11: OFF None

Filter 12: OFF None

Filter 13: OFF None

Filter 14: OFF None

Filter 15: OFF None

Filter 16: OFF None

Filter 17: OFF None

Filter 18: OFF None

Filter 19: OFF None

Filter 20: OFF None

[bibo01]

The 2 pairs of arrow keys on the keyboard are both used for volume and change track, it depends if one with the cursor has activated volume or track change. Since one alternates almost always between the two operations, when you go to change volume you actually change track. A simple solution would be to have two fixed keys to change track and especially another two fixed keys for volume.

To change track the cursor is fine, but fine volume adjustment can only be done through keyboard keys. So the implementation must be functional.

I'm not sure what you are talking about...

 

I have tested the functionality on couple of multimedia keyboards and it has been working fine. Play/Stop/Next/Prev/Fwd/Rew buttons act on tracks and VolumeUp/VolumeDown/Mute buttons act on volume. I've tested this on both Logitech and Microsoft keyboards that have multimedia-keys. Also Apple IR-remote works correctly on Win8.1 installed with BootCamp. Remote controls from other vendors are likely to work correctly too.

Sorry, I did not make myself clear.

 

In order to change volume, firstly I have to click on the Volume knob, then I can use up/down or left/right keyboard keys to change volume.

If I do not click on the volume knob, with the same keys I inadvertently change tracks.

 

What I was requesting is two keyboard keys that are always connected to volume change and are separate from other functions, without having to select volume knob first.

For example, up/down keys could be reserved to volume and left/right keys could be for track change.

 

Happy New Year!

[sfox7076]

Hope this helps...

 

I'm using 3.12 with Yosemite on a Mac Pro 6,1 (quad core) and it works flawlessly with all flavors of poly-sinc*-2, poly-sinc-ext, and closed-form at DSD256 to an iDSD Micro.

 

I don't know if this is an issue, but I'm unable to use any of the non "-2" poly-sinc filters (with "Pipeline SDM" enabled or disabled). HQPlayer just sits there when I attempt to start playback (EDIT: I was impatient, playback starts eventually).

 

 

EDIT: I experimented a bit with "poly-sinc" (not the "-2s" version).

 

With "Pipeline SDM" both on and off

 

All tests with ASDM7

 

DSD256: Takes 30 seconds or more to start, solid stuttering

DSD128: Takes 20 seconds to start, sort of plays without stuttering but is unstable and the slightest additional load on the CPU will cause stuttering and clicks. The "top" command here shows CPU usage of HQPlayer is 215% (using over two cores constantly)

 

Using "poly-sinc-2s", DSD256 is solid on this Mac. The "top" command shows CPU usage of HQPlayer to be 145% (using less than 1.5 cores).

 

 

Same here on my late-2012 Mac mini.

[bibo01]

I'm using Roon & HQPlayer together and am experiencing a loss of connection between Roon and HQPlayer. This happens at the end of a song and I have to shutdown and restart HQPlayer before I can play music again.

 

Anyone else experiencing this? I'm guessing it's a HQPlayer bug since restarting the HQPlayer app fixes it.

 

There is no need to restart HQPlayer. In Roon open Volume, click on the chain icon.

[firedog]

There is no need to restart HQPlayer. In Roon open Volume, click on the chain icon.

 

and then click on play in Roon again.

 

Sometimes just clicking on play in Roon again will restart the music.

 

Hopefully Miska and the Roon guys will figure out the cause of the loss of connection and fix it. I haven't found a consistent pattern - sometimes it is at the end of a song, sometimes at the end of a playlist, sometimes when a playlist contains mixed formats or sample rates. But other times the same elements seem to work without issue.

[Miska]

Hopefully Miska and the Roon guys will figure out the cause of the loss of connection and fix it. I haven't found a consistent pattern - sometimes it is at the end of a song, sometimes at the end of a playlist, sometimes when a playlist contains mixed formats or sample rates. But other times the same elements seem to work without issue.

 

I think I may know what is going on. But I would need some more information to have better picture. HQPlayer stops the playback when it encounters a conflict between requested settings and source format. So let's say you ask Roon to play two tracks, one is 44.1k and another one is 96k. In HQPlayer you have selected closed-form filter and output rate is 5.6 MHz DSD. First track plays fine, when the next track is encountered playback will stop because closed-form cannot convert 96k to 5.6 MHz (while for example poly-sinc can). At this point Roon may think that HQPlayer GUI was acted on, because the state changed even though Roon didn't ask for it, and due to this Roon gives up the control. Clicking Play again in Roon should resume the connection and playback may continue if the settings are otherwise OK (you may need to adjust the settings at HQPlayer side if there was a conflict).

[Miska]

What I was requesting is two keyboard keys that are always connected to volume change and are separate from other functions, without having to select volume knob first.

For example, up/down keys could be reserved to volume and left/right keys could be for track change.

 

Those already exist, those are volume up/down keys! And for tracks there are the corresponding track control keys.

 

For example Logitech K200/K270 keyboard has some of those keys (four, Play/Pause + Mute + Volume Down + Volume Up). K350 has also track control keys.

 

Happy New Year!

 

Happy New Year!

[firedog]

I think I may know what is going on. But I would need some more information to have better picture. HQPlayer stops the playback when it encounters a conflict between requested settings and source format. So let's say you ask Roon to play two tracks, one is 44.1k and another one is 96k. In HQPlayer you have selected closed-form filter and output rate is 5.6 MHz DSD. First track plays fine, when the next track is encountered playback will stop because closed-form cannot convert 96k to 5.6 MHz (while for example poly-sinc can). At this point Roon may think that HQPlayer GUI was acted on, because the state changed even though Roon didn't ask for it, and due to this Roon gives up the control. Clicking Play again in Roon should resume the connection and playback may continue if the settings are otherwise OK (you may need to adjust the settings at HQPlayer side if there was a conflict).

 

I would think this assessment spots the issue, except for one problem: for the past week I've only had HQP set to upsample all material to DSD 64 with either poly-sync-shrt-mp or poly-sync-shrt-mp-2s. My understanding is that there shouldn't be the type of issue you are describing under this scenario. Am I wrong?