HQ Player

[Jud]

I am not Jud but I am running HQP on Lubuntu 16 without issues. As I understand Lubuntu and Xubuntu are very similar.

 

They're Ubuntu with different interfaces and different choices for suites of apps, but much of the same "plumbing."

 

Edit: I can't think of anything that would cause HQP to work on one variant but not another.

[Jud]

I'm trying to get HQPLAYER install on their Live build.

 

Nothing installs on the Live build. That build runs from a read-only medium.

[Jud]

If my memory don't fail me (in most cases it does) RAM usage brought some positive results with Amarra or A+. As OS optimization tricks, etc. It was lightyears ago, HQP is great to use without stressing OS.

 

I think I hear greater improvement simply by keeping my music library on a drive accessed by network (Ethernet) rather than FireWire or USB. Since the other OSX player I use is a memory player that likes RAM and Miska doesn't think it makes a difference, I've pretty well abandoned playing around with RAMDisks on OS X.

[Jud]

There is now 3.14b5 available with following changes:

 

- Some compatibility fixes for older Macs with older CPU models

 

Thanks, Miska. Would that happen to include my mid-09 MacBook Pro with 2.53GHz Core 2 Duo?

[Jud]

Thanks for these references. I've found #2 to be the most relevant. I will try the sinc filter and also try to avoid the upsampling altogether, as well as do the planned A+ comparison.

 

My current guess would be that the problem lies with using any upsampling full stop, as I had never used upsampling in A+ and had never experienced this sort of 'disorientating' feeling that I'm hearing now from poly-sinc upsampled tracks on HQP.

 

If you don't upsample, the filter does not operate. That's what the filters do, deal with the results of upsampling.

 

You've always used upsampling, as it's been built into pretty much all DACs for decades (going back to CD players, before there *were* such things as separate DACs). The upsampling in HQPlayer or A+ is doing the same stuff as happens inside your DAC; they just do it differently and possibly better.

 

Now what's "better" by some measurements chosen by the filter designer, and what you like to hear can be quite different things. No problem, listen to what you're happy with.

[Jud]

Charles Hansen of Ayre has some very strong opinions about digital sound reproduction. I suspect he has made some unusual design decisions with the QB-9 filter and dac implementation.

 

The Ayre's filtering is quite public (subject of a white paper), and there's no particular reason it should be incompatible with HQP. Its filtering does sound quite good (to my ears, anyway) and it wouldn't surprise me if at least some people prefer its sound to that of various HQP filters.

[Jud]

Since the "listen" filter is extremely leaky filter it produces lot of images in ultrasonic band which significantly increases amount of intermodulation products in the audio band.

 

If you compare to HQPlayer, "measure" filter on QB-9 is closest to poly-sinc-short-mp. And "listen" filter is closer to either polynomial filter or minringFIR, although the "listen" filter is minimum phase too unlike the polynomial or minringFIR which are both linear phase. So Ayre's both filters modify phase response.

 

If you have QB-9 DSD, it is probably best to use it in DSD mode which would hopefully bypass Ayre's digital filters. Too bad it is limited to DSD64 though...

 

I think something similar is used in the Pono, and I like the sound of that too. So the IMD is apparently something that subjectively appeals to me (and others, if various reviews and owner reactions are anything to go by).

[Jud]

Here is a theoretical idea being discussed a bit over on the T+A thread. These are my takes on what I am calling a proposed option called "HQP Offline".

 

Since DSD512 realtime upsampling is so cpu intensive and requires some major hardware commitment, and since many have asked for other GUI front ends for HQPlayer, what about this crazy idea: Jussi develops an offline capability to upsample (using same choices of filters, modulators, etc) to, say, DSD512 (or whatever). Yes, the storage requirements are massive, but it's not like we all listen to ALL of our library anyway. Offline upsampling cold be done on a need to hear basis, of course.

 

My stupid brain says this might free up the cpu needs somewhat (i.e batch process the upsampling overnight and let lower powered cpus take their time doing the work since this is not required realtime) and maybe free up playback to most any player or control point/renderer (assuming the final playback stage of HQP is not anything required....I do not know cuz I've never played HQPlayer in "passthrough" mode). Just spit-balling here.

 

My $.02

 

Would like to see it myself, and actually asked Miska about it some time ago. However, he had various reasons for not wanting to do this. And even though it's against my self-interest, another reason not to do it from my point of view is that it may make reverse engineering his filter designs easier.

[Jud]

Hi Miska. Just got a SEEED BeagleBone Green Wireless board. Should the NAA image work without modification (other than specific settings for my wireless network)?

[Jud]

Curious if wireless N is fast enough for DSD up to 256??

 

Wireless N is 450 Mbps. Sample rate of DSD256 is 11.2Mbps. I think that leaves sufficient margin.

[Jud]

For any wireless cases it is better to go for Debian Stretch and the Debian package I provide instead of my NAA image. My NAA image is really minimal and doesn't contain necessary components for configuring wireless use.

 

The full OS image I provide is designed to be "plug and play" without need for any configuration. But of course that kind of doesn't work with wireless where you need to set at least SSID and the key.

 

Good thing is that Debian Stretch officially supports BBB, so the installation is pretty seamless and things get updated frequently.

 

Thanks!

 

(By the way, I've been looking for a 5v iFi iPower for the board, and the usual online outlets seem to be out of product. Anyone know of one of these in the USA available for purchase? I also intend to ask over on the iFi sponsored forum.)

[Jud]

Setting "Buffer time" to "Default" at HQPlayer side means "use the buffer size proposed by the driver". With ASIO, most drivers have control panel where such adjustments are supposed to be made. If a driver doesn't have an ASIO Control Panel, then HQPlayer can try to control it's buffer size. Some drivers say that they support only single buffer size (possibly the one set in their control panel) - then HQPlayer just ends up using that one regardless what is set in the "Buffer time". I think I'll add couple of words about these ASIO details to the manual...

 

Note; with the Thesycon driver used by iFi and many others, the set of available buffer sizes are relatively small and clearly originally thought for PCM rates between 44.1k and 192k. At higher PCM and DSD rates the buffer sizes become relatively small and thus even with the highest setting are relatively short in time. So for example with iFi iDSD DACs, it is best to select the biggest/safest buffer sizes in the ASIO control panel and leave the setting at HQPlayer side to "Default".

 

Situation with Linux for these DACs?

[Jud]

On Linux iDSD Micro/Nano of course work just fine, no need for DoP or such. All DSD rates, including the 48k-base ones which are not available through the ASIO driver (limitation of the driver, not the hardware).

 

On Linux, the buffer size management is done by HQPlayer.

 

Thanks, it was the buffer size management I was interested in. I have not been using DoP with Linux. Strangely, I could use DSD256 a few weeks ago, but not now, and that is whether the DAC (iFi micro-iDSD) is connected to the Linux desktop or NAA (CuboxTV). (Edit: When I say I can't use DSD256, I mean there is constant stuttering.)

[Jud]

Hi Miska - Idly thinking about trying TrueOS (a FreeBSD-Current fork, see https://www.trueos.org/more-on-trueos/), wondering what sort of effort would be involved in making an HQPlayer build that would run on *BSD, and whether you would be even the tiniest bit interested in doing so.

[Jud]

It would require writing a new backend to support the audio API used on BSDs. Other than that, probably not much changes needed, assuming Qt-5.6.x+ being available through ports.

 

https://www.trueos.org/blog/ - "One core philosophy behind the development of Lumina [the TrueOS lightweight desktop environment] has been to use nothing but pure Qt5 for all underlying utilities."

[Jud]

I want to run HQPlayer using a network drive as the source of the library. That is, I would like to run HQP on my laptop downstairs while accessing music stored on an HDD attached to my upstairs desktop; or run it on the desktop while accessing music stored on an HDD attached to the laptop downstairs. (I realize I can do something much like the first of these by running HQP on the desktop through the NAA downstairs. Still, I'd like to be able to do all three.)

 

The laptop downstairs can access the files on the upstairs HDD via my network, and vice versa with the upstairs desktop and downstairs HDD. However, when I try to add upstairs HDD files to the library of HQP running on the laptop downstairs, or files from the downstairs HDD to the library of HQP running on the desktop upstairs, it doesn't work for me.

 

Does HQP not accept files from network attached drives, or is there something I'm not doing correctly?

[Jud]

Interesting. I have the same setup downstairs as Miska (upstairs network attached HDD mounted on OS X as /Volumes/Music), so I'll have to look into this a little more.

[Jud]

Don't know what this particular model might do for HQPlayer capabilities, but Gigabyte GeForce GTX1060 is on sale at Newegg for 48 hours (from midnight Pacific today) at $239.99 with manufacturer's rebate.

[Jud]

What is the difference between NetworkAudioAdapter and NetworkAudioAdapter IPv6?

 

Network Audio Adapter can use either Internet Protocol (IP) version 4, the old system that everyone's network supports, to communicate with the HQPlayer computer, or Internet Protocol version 6 (IPv6), the "newer" system that has been around for many years but not everyone's network supports yet.

[Jud]

Thank you. Do you find any difference in terms of SQ?

 

My eero routers don't yet work with IPv6 (though they say a firmware update will be coming soon to enable this). But I wouldn't expect at all that a different form of network address identification would change the sound.

[Jud]

For home routers that contain low-layer switches don't need changes to enable IPv6 networking, because they operate at the level of ethernet packets. But it means the IPv6 may need to be manually configured with fixed IP's (SLAAC could still work in the network even if router doesn't support it).

 

For higher level managed switches that operate on IP protocol layer changes would be needed to enable IPv6.

 

For example Apple AirPort gear is IPv6 ready and new equipment from many other vendors too.

 

 

All I know is what I read .

 

See https://support.eero.com/hc/en-us/articles/207852833-Does-eero-support-IPv6- -

 

Does eero support IPv6?

eero doesn’t support IPv6 yet, but look forward to this in the near future!

 

 

 

In any case, I don't feel any lack in my home network, either generally, or specifically concerning NAA. HQPlayer performance is limited by my old computers (mid-2009 Core 2 Duo MBP, late 2009 i7-950 desktop with Windows and Linux currently, probably TrueOS soon [was PC-BSD, a variant of FreeBSD]) rather than the network.

[Jud]

Sorry if it has been asked before. What is the difference between poly filters and poly-2s?

 

The -2s filters are easier on your computer, while having performance not equivalent to the non -2s filters, but as close as Miska can make them. If you are having problems (e.g., stuttering) with HQPlayer filters, try the -2s equivalents.

[Jud]

Please first check that the DAC has not been set as default audio output device in macOS. Then make sure DAC is selected as the audio device in HQPlayer and that there are no other applications running that would try to access the device simultaneously (no black dots in the Dock).

 

The dots will be at the bottom of app icons in the Dock for any app that's running and therefore might be using your DAC. The dots will be light if you use the dark theme.

[Jud]

i OWN a MBPr mid 2012 2.3 i7, much more powerful than the MBPr end 2013 in the house too and it's plain impossible to use 3.14. If a 2.3 i7 is obsolete per HQP standard, should you reconsider or should I ?

 

At the moment I haven't taken enough time to decide if I go back to 3.13.3 or 3.14 beta 4. Very different sound. Want to love the snappier lighter 3.14 beta 4 but might not be the summer that led me to listen less (starting with the 3.14 betas) and mainly vinyl, as if HQP magic was gone...

 

One thing is sure :can't use any of the 3.14 releases.

 

OK I'm convolving but....

 

Cuda outputs no sound and pcm to dsd stutters (CUDA unchecked, pipeline enabled or not)

 

As of 3.13.3, CUDA takes a good part of the CPU burden when the source is DSD. Might make sense to disable CUDA with GC with less than 2G for PCM to DSD conversion but allowing DSD to DSD upconversion + convolution with CUDA might be a good idea. Drawback is that with CUDA enabled (3.13.3, DSD to DSD) the machine seems to suffer more globally with temperature raising in the 88 at GC sensor and lot of fan noise ; CPU usage goes down to 15/16 % on the other hand)...

 

Keep the good work, cheers, but I think something is wrong with 3.14...

 

Convolving must be the key, because I'm running PCM to DSD256 conversion with a mid-2009 MacBook Pro with Core 2 Duo CPU, and a late 2009 self-built Linux machine with an i7-950 (with the latter, up to PCM 352.8KHz to DSD), both without more than a very occasional stutter (a couple of times an hour if that).

 

To help with the fan noise problem, you might consider an NAA (which is how I'm using the Linux machine).

[Jud]

I've updated HQP Desktop to the latest 3.14.2 version and it cannot find the NAA.

 

I am using a direct Ethernet connection between the Macbook Pro and the Raspberry-Pi.

The NAA version is networkaudiod_3.4.0-32.

 

Fortunately I have kept the 3.13 version so I can still connect to the Pi/DAC.

 

R

 

Did you try unplugging and reconnecting the NAA power?