HQ Player

[k6davis]

Miska,

 

Would you consider adding an option in HQP for volume leveling? It's a feature that I've found greatly improves the listening experience. It allows for recordings with greater dynamic range (and consequently lower overall volume) to be appreciated without the impact of the increased loudness of the more compressed recordings.

 

Plus it obviously eliminates having to ride the volume so much during a listening session where different albums are played. And the discomfort of the "blast" when switching from a quieter recording to a louder one, especially when listening at a higher level in the first place.

 

If there are concerns about the impact this would have on overall fidelity (loss of resolution due to digital changes to volume, for example), it could of course be an option that's turned off by default.

 

Here are a few words about how another developer implemented it (I underlined some passage for emphasis):

 

Have you ever put on an album and noticed that it was drastically louder than the last album you were listening to? Everyone has a few albums that every time you put them on you race for the volume control to turn them down. Similarly, I'm sure you've heard albums that were "too quiet" and you had to turn them up quite a bit to hear them at all (only to go racing for the volume control again when you followed them up with a loud one). This is the result of the fact that (unlike film) there's no loudness standard in audio engineering. Because louder audio is often perceived as sounding better, there has been a "loudness war" in mastering music to try and make the loudest sounding music possible, often through compression (reducing the Dynamic Range to make more of the song "loud"). One unfortunate side effect of the loudness wars is that albums have drastically varying average volume levels.

 

Volume Leveling is a solution to this problem. It does it by analyzing the "loudness" and dynamic range of the music (using the international standard R128 analysis method), and then adjusting the volume level of the music to a reference level. The result is that most music will sound close to the same average volume with volume leveling on. Volume leveling does not compress the music or affect dynamic range; it just changes playback volume. Volume Leveling also does not alter the audio content of files; all volume adjustment is done using DSP at runtime.

 

The [R128 analysis] information is stored in in the file itself, so that playing the file with any compatible player will play it back at the reference volume.

 

 

Thanks,

Keith

[k6davis]

Hello Miska.

 

I've been a happy HQPlayer customer for a few months now.

 

I recently upgraded my Lampizator DSD-Only DAC to DSD256 capability and everything works fine.. except... I greatly prefer the sound of my system with jPlay & dual servers, and jPlay only processes SDM via DoP. It seems that I have a DoP ceiling of DSD128.

 

Do you have any idea if it's possible to send DSD256 via DoP to any DAC? My DAC uses the Amanero Combo384 USB interface.

 

Thanks,

Keith

[k6davis]

Hi Keith,

 

Yes, it's possible. Quad DSD should play fine via JPLAY now. Which version are you running?

 

Cheers,

Marcin

 

Thanks to everyone for your clarifying responses.

 

Marcin, is that statement true for DACs that only accept DSD256 via ASIO? Because it seems that my DAC can't accept a DSD256 DoP stream.

 

I'm running jPlay 6.1a, which I believe is the latest version.

 

Thanks,

Keith

[k6davis]

No, you need to do ASIO DSD to reach rates higher than DSD128, because PCM rates are limited to 384k. DoP also has 50% data transfer overhead.

Thanks Miska

[k6davis]

Hi Keith,

 

No, because JPLAY can play DSD only via DoP (Kernel Streaming). I checked Amanero and it seems it can do DSD via DoP up to DSD128 and for anything higher you need to use ASIO. JPLAY can't play DSD via ASIO.

 

Regards,

Marcin

 

I'm just seeing this. Thanks for your reply Marcin.

 

I hope you're considering adding DSD playback via ASIO. I've assembled a system that I'm very, very pleased with. I only recently discovered how much jPlay, the dual severs, hibernate, etc. contribute to it. I'd love to enjoy DSD256 with my DAC, but I refuse to give up jPlay period!

[k6davis]

Any news on Roon + HQPlayer integration? The early rumours were for something to happen about now

 

Thanks

 

Following on from my Roon+HQPlayer integration question I dropped Roon onto my server today. Fun set of capabilities, but a shame about the sound quality!

 

Back to HQPlayer

+1

 

I couldn't agree more with both posts. I'm hoping for some progress with Roon+HQPlayer integration (as are a lot of people on the Roon forum) but AFAIK, there haven't been any status updates.

[k6davis]

I also installed the beta in order to play ROON with HQplayer - but suddenly I cannot even get HQplayer to upsample my material to DSD128 anymore. I have a Mac Mini (mid 2011, i7, 2.7GHz, 8GB memory), which until now have been able to upsample without any serious problem. But now I get stuttering for any files above CD quality.....What has happened to the HQplayer in the last update that have made it more cumbersome for my Mac mini to use it??

 

I'm having a similar experience. I run a Core i7-3770S 3.0GHz on Windows Server 2012. My server doesn't have CUDA. With 3.11.0, I was able to upsample any source file to DSD128 with any combination of algorithms. With beta3, poly-sinc stutters badly and I have to use poly-sinc-2s. Adjusting the buffers and selecting Pipleline SDM doesn't help. I tried switching back to 3.11.0, and the server easily handled poly-sinc with all of the same settings.

 

Unless I'm doing something wrong, beta3 doesn't perform as well as 3.11.0 on my server.

[k6davis]

Apparently a MAC issue of the beta. On Windows I'm using poly sinc filters with no issues.

 

I'm having trouble running poly-sinc in beta3 on my Core i7 Windows Server machine. poly-sinc worked fine in 3.11.0.

 

Miska recently posted that he believes he knows what the issue is and he will provide an update that will fix it soon.

[k6davis]

I experience the same problems with stuttering. I thought upgrading from i5 4590 to i7 4790k will solve the problem, but I am still not able to get any upsampling from PCM to DSD64, 128, 256 working without stuttering or clicks. The CPU load is not really high (15-40%) and I don't know where the bottleneck is.

 

I am using Win7 and a Merging Technologies Hapi.

Do you have the same difficulties with the official version 3.11.0 and with the current beta version (beta3)? If not, a fix is in the works for the beta that might help.

 

I run a less powerful Core i7 than you and I have no trouble upsampling to any input to DSD128 or DSD256 with poly-sinc - in HQP version 3.11.0.

[k6davis]

I recently upgraded from a Core i7 3770 to a Core i7 6700. I upsample everything to DSD256 with poly sync & DSD7. Of course, everything is faster and runs cooler with with lower resource utilization, but the load times for the various upsampling filters and algorithms didn't improve as much as I'd hoped for.

 

This is such a simple idea that I'm sure it's already been considered, but here it goes anyway.

 

Given enough computer resources, is it feasible to offer an option to load several different sets of the filters and algorithms into the computer's memory at once and switch between them as the source material requires? That way there would be one long wait at the beginning of a session, but no wait after that. If this were possible, I'd want to load filters for the following source content, all at once: Redbook, 24-96, 24-192, SACD/DSD x 1.

 

Maybe there's something that could be changed in my settings or configuration, but (particularly) when going from Hi-Res PCM back to Redbook, the filters have to load again, as if I'm starting a brand new listening session.

[k6davis]

I was having some issues with the currently released version of HQP involving the stability of HQP/Roon/NAA Daemon integration and a long standing annoyance with the song progress bar/slider handle being absent in Windows Server 2012. I was about to compose an message asking if Miska could look into these issues, but it occured to me to try out the latest beta version of HQP first.

 

Boom... All of the my concerns had already been addressed in Beta 5. Thank you Miska for your continued improvement of an outstanding product.

 

By the way, in terms of UI, stability and sonic performance, the HQP/Roon/NAA Daemon combination is superb!

[k6davis]

Please remind me what you are using for an NAA?

In pursuit of the best performance, I tried the microRendu, but I found that I got better sonic performance with the HQP NAA Daemon software running on Windows, of all things, even on the unoptimized laptop that I initially used to test the configuration. I understand that this should not be the case, but it was for me, and the difference was obvious. I've long been a proponent of isolating the upsampling/DSP computer from the DAC, having used jPlay for this purpose previously, but HQP and it's NAA Daemon gave me the best sound I've ever gotten out of my system.

 

The fact that I can run DSD256 into my Amanero DAC with the NAA Daemon/Windows while I'm limited to DSD128 with the Linux based solutions may account for some of the difference, but I don't think that's the whole story.

 

Since I've long had a dual Windows 2012 Server setup, I decided to run Roon and the NAA Daemon on one server and HQP (alone) on the other, both treated with Audiophile Optimizer. The resulting sound quality makes me very, very happy.

[k6davis]

I was thinking the same thing. Isnt the NAA supposed to be on a device that has no other process running to minimize noise as much as possible?

 

Why not use Roonserver on the machine running HQP then use Roon remote on an tablet or another pc/laptop? That would help to reduce processing demand on the HQP pc.

According to Miska, the NAA application is doing very little, by design. It seems to be fairly impervious to other activity running on the machine, within reason. I got the best sound ever (at that point) when I was just doing a functional test with the NAA Daemon running on a general purpose, untreated Windows 10 Laptop. I would speculate that the biggest improvement from using an NAA comes from the isolation of the workhorse upsampling DSP machine from the DAC as opposed to how optimized the NAA machine is. I realize this runs counter to other's experience and that the idea you and teb_b are expressing makes complete sense. I'm just conveying how it worked for me.

 

From there, I decided that, given I had two servers to work with, I'd try giving HQP full access to the more powerful of the two. The sound clearly and significantly improved when the most demanding process, the HQP DSP had a server to itself and didn't have to share resources with Roon.

 

So, I got 3 upgrades (NAA Daemon, DSD256 for my Amanero DAC, and HQP having a machine all to itself), each of which improved the sound separately but work like magic together! And none of it cost me any (new) money!

[k6davis]

1000 thank you's Miska for the recent improvements to the NAA app. I used to have to go through a frustrating power cycle on my Regen and go into HQP's settings to reconnect to my DAC at each session, but no more. It was an annoyance that was well worth the excellent sound HQP gives me, but now it's gone!

[k6davis]

Songs are randomly stopping just before they end for me too with my HQP/Roon combo. But for me, it's not happening because of sample rate changes. It happens for me even when I'm repeating a single track, but not in any predictable way.

[k6davis]

On 7/22/2017 at 1:33 PM, firedog said:

I have the same issue. Playlists in HQP/Roon pairing stop at the end of songs.

 

On 8/1/2017 at 1:26 AM, clipper said:

I went back to HQP version 3.15.1.  

 

No problem now.  It will play all day without stopping.

 

On 8/1/2017 at 7:03 PM, Miska said:

 

Yes, seems to happen at the end of DSD track if next track is a PCM track, but not if next track is a DSD track.

 

I'm still having this issue with version 3.17.0. I went back to version 3.15.1 as clipper suggested and like he said, the older version doesn't have the issue at all. Thanks clipper.

 

Unlike what others are experiencing, my system will hang at the end of a track, randomly, regardless of the format. I can put a PCM file on repeat and it will hang at the end after a few plays. The fact that the Roon/HQP combo doesn't have this problem with the older version of HQP suggests to me that the issue is on the HQP side - if it's not something in my configuration, which is of course a possibility. I'd like to stay current with HQP,  but not with the interruptions. 

 

I'd be happy to provide any additional info or logs to help diagnose the problem.

[k6davis]

16 hours ago, Miska said:

 

I'm suspecting Roon is incorrectly assuming the playback position time from HQPlayer to be reliable and to ever reach end of track, which it is not and which it may not. It is plainly informative. Only the playback state is reliable and that's the only information Roon should be looking at. In fact Roon should queue next item to HQPlayer queue way before the current item ends. But it doesn't do that. But of course I cannot know what exactly Roon is doing with the data it gets, I only know how the HQPlayer control protocol works at HQPlayer side, not how other applications use it.

 

You know roughly a million times more about this than I Miska, but whatever the shortcomings of Roon's API, it does work perfectly with HQP 3.15.1 but not with HQP 3.17.0.

 

It doesn't seem that many others are having the issue, although clipper said he also had to revert to the older HQP version for the same reason. 

 

Is there any info I could provide you to help figure it out? I'd be willing to discuss it in PM's if no one else is having the issue.

[k6davis]

HQP just keeps getting better and better.

 

The latest version (3.18.0) features "optimizations". One thing I've noticed is that, with successive updates, the delay I used to experience when switching between tracks of differing resolutions or formats (upsampling everything to DSD256) kept lessening. Now it seems to be gone completely.

 

I also wanted to mention that I'm really enjoying the sound of poly-sync-hb. I've got no idea what "hb" is , but I wanted to mention it because I hadn't seen anyone else do so.

 

The combined strengths of Roon & HQPlayer (both continuously improving) have led to a truly gratifying listening experience. 

 

Thanks Miska

[k6davis]

I've built a new server for HQP and at this point it doesn't have a case. I'd like to buy the license for HQPE, but I'm wondering if you have any idea if the case I (eventually) choose would alter the licencing fingerprint - since it'll be connected to the motherboard.

 

Everything is working great, so I don't intend to make any changes to the main components of the computer. I'd like to remove the 30 minute limit while I take my time picking out a case.

[k6davis]

Due to a limitation caused by the Amanero card in my DAC, I have to choose between DSD 256 with 48k ability and DSD 512 without 48k ability. From a technical perspective, which of these is preferable?

 

Asked another way, is worth it to convert 48k based material to 44k rates in order go from 256 to 512?

[k6davis]

7 hours ago, Miska said:

 

Even with the latest Amanero firmware release (about one week old now or so)?

 

I had no idea they'd finally released firmware to resolve the Amanero DSD 512 issue!! I updated the USB in the DAC card it's working great!

 

Thanks Miska 👍

[k6davis]

1 hour ago, Superdad said:

One thing that I can’t figure out is this:

HQ Player has never directly supported MP3 files. So how is it that Roon manages to play my MP3 tracks (you know we all have some) through HQPe?  I thought Roon only passes files through to HQP without any processing.  Mind you I am not complaining—it was a pleasant surprise once I pointed Roon at my whole music library.  I am just puzzled.

(Sorry for the large text.  Pasted from an email and I’m on my phone.)

 

Roon appears to send everything out at a minimum of 16/44.1, which is ideal for its integration with HQPlayer. All of your Redbook, HD PCM and DSD are sent at their native rates and any lossy files (including lossy internet radio streams!) are upsampled to/sent out as 16/44.1. Therefore, anything that Roon can play can be consumed and upsampled by HQPlayer.

 

File this under possible placebo, but I also prefer the way the music sounds when Roon is feeding HQPlayer - even with Redbook and higher resolution files. I know there shouldn't be any difference, but I hear one.

[k6davis]

On 6/26/2019 at 9:58 PM, Jerry said:

I'm mainly using Tidal -> Roon -> HQPlayer -> sinc-M -> AMSDM7 512+fs -> DSD512, and the main source is 44.1kHz lossless red book of classical and indie. My hardware is iBasso DX220 feeding to Astell&Kern Beyerdynamic AK T1p. 

 

I have a relatively powerful PC running HQPlayer, so would like to fully utilises the computational power to improve the sound quality. What would be everyone's favourite filter setting?

 

I'm using NAS -> Roon -> HQP OS -> poly-sync-hb -> DSD7 256+fs -> DSD512 -> HQP OS (NAA) -> ISO Regen -> Mapleshade USB -> Lampizator L4 DSD Only Preamp/DAC -> PurePower SE Amp -> Magnepan 3.7i. 

 

About a year ago, I upgraded my HQP server to an AMD Ryzen 7 2700x (8 real + 8 virtual cores) so I could experiment with the more demanding filters, but poly-sinc-hb remains my favorite. It doesn't require a powerful processor to run and I don't think Jussi thinks that highly of it but it sounds amazing in my system.

 

The other (more popular) combinations make the music sound like a superb recording but with "hb" and "DSD7", it sounds like the performers are in the room. There's a sense that transients come out of... nothing. They're clear, as they should be, but you can better hear the space between them. Also, the texture of each instrument and its ambience is more distinct. 

 

I don't know how you can have a "best" HQP setting. All of our systems (and rooms) are completely different and that doesn't even take into account personal taste. But I wanted to contribute my .02 - especially since it's a unique opinion.

[k6davis]

37 minutes ago, Jerry said:

Thank you for your feedback, just a bit curious your choice of DSD7 256+fs instead of AMSDM7 512+fs. I agree there's no "best" filters, but given the idling processing power, I'm looking to fully utilises it even it only yield marginal improvement.

I've tried them both. Again, in my system and to my ears, DSD7 256+fs definitely sounded better than AMSDM7 512+fs. I wish there was a DSD7 512+fs.

 

Beyond that, the AMSDM7 512+fs modulator doesn't use more system resources than the DSD7 256+fs, or even the AMSDM7 modulator. It's just optimzed to sound better with (and will only function at) 512 or higher. The DSD7 256+fs is optimzed to sound better with 256 or higher, which obviously includes 512. It's the filters that have a huge variance in the amount of processing they require. If I'm wrong about any of that, someone please correct me.

 

Going further still, there's a line of thinking that having a heavy load on your server can negatively impact the sound. I'm not sure if that's true, or if it is, where the line is. Like I said, I upgraded my server to try out the more "intense" options, but the settings I referred to above gave me the best sound - and by a considerable margin. Maybe it's because my relatively powerful machine is loafing and separated from the DAC with an NAA. I don't have the technical understanding to know why, but I like what I hear.

 

My approach is to experiment (especially when it's free, like these options are, or cheap) with no expectations about what ought to be best. 

[k6davis]

19 hours ago, craighartley said:

Miska,

When will we get the new EC modulators in HQP Desktop 4?

 

EC modulators (???)