HQplayer 4 and Mac-mini M1

[camott]

Can someone do me favor and see if the new poly-sinc-gauss-xla can run at 1.536mhz PCM on the M1 Mac Mini? Thanks in advance!

[camott]

On 7/15/2021 at 3:44 PM, camott said:

Can someone do me favor and see if the new poly-sinc-gauss-xla can run at 1.536mhz PCM on the M1 Mac Mini? Thanks in advance!

 

So I ran some HQPlayer performance tests on my i9-9980HK MacBook Pro 16 using the null output. 24/192 → 1536 with gauss-xla could not quite do 1x processing speed with no multicore DSP (2 cores). With multicore DSP set it used 4 cores and was able to process almost 2x speed. Given that the M1 single core is about 25% faster than my 9th gen Intel i9, it should be able to do gauss-xla at 1x speed a bit under 50% utilization on the 4 high-power cores. Maybe even possibly without multicore DSP but the two cores would likely be pegged. Next step is to order one and actually try it out.

[camott]

8 hours ago, Miska said:

 

Multicore DSP should be set to grayed (auto) which usually gives best overall performance in playback cases.

 

 

Where does this figure come from? At least it is not the case comparing my M1 Mac Mini to my iMac with i9-9900K, where single core of 9900K is about 2x faster than single performance core on M1, under HQPlayer loads.

 

 

So I am unclear on auto multicore vs forced multicore ...

 

Below are the performance numbers I got in each of 3 modes for a 24/192 file -> 1.536M using poly-sinc-gauss-xla + LNS15 output to the null device. The play time of the 24/192 file is 4:55. Again, cpu was i9-9980HK in MacBook Pro 16.

 

no multicore - took 5:42 to process 4:55 file with two cores fully maxed. Obviously not fast enough.

 

97.9% CPU

98.8% CPU

 

multicore forced (checked) - took 3:11 to process file with 4 cores around 90% utilized and 2 partially utilized. sample:

 

9.0%

9.1%

86.8%

87.5%

87.5%

88.6%

 

auto multicore (grey) - took 2:38 to process file with 6 cores around 80% utilized and 2 partially. 

 

14.7%

14.9%

80.1%

80.4%

80.4%

80.5%

81.5%

82.0%

 

 

So, auto multicore used roughly 50% more CPU for a pretty small increase in performance. I got very similar results with 16/44.1k -> 1.411M. (Note that I have tried these tests multiple times and the results are consistent). What I don't understand is why auto multicore uses 2 additional cores than forced multicore.

 

Regarding performance of M1 core vs i9 9th gen - this was based purely on various benchmarks I have seen comparing M1 vs i9-9980HK, be it cinebench or geek bench or whatever. They all suggest that the M1 is slightly faster in single core tests. But they also give similar results for your i9-9900K. So not entirely sure why your real world tests with HQPlayer suggest otherwise - I suppose those other benchmarks are testing more than pure cpu which is what HQPlayer is all about (vs memory bus etc)? One thing I will note is that your i9-9900K has a baseline frequency of 3.6Ghz whereas my i9-9980HK for above tests has a base frequency of 2.4Ghz.

 

Can your M1 do 1.411/1.536M PCM with guass-xla??

[camott]

@Miska one further question for you. guass-xla takes slightly longer to process 1x 44.1 -> 1.411 than it does for Nx 192 > 1.536 in my benchmark tests. i.e. 1x has just slightly heavier load. All else equal (same track etc). Why is this? I had thought that the same filter for 1x was a lot faster than Nx (and thus why you have separate 1x vs Nx settings). But in this case the pattern doesn't hold. Is this particular to gauss filters or ???

[camott]

1 hour ago, Miska said:

That is not the reason for separate filters. But the reason is that for hires material you may want different kind of filter.

 

Ok thanks. I guess I was confused because often it seems like people use ext3 for 1x and ext2 for Nx, which I assumed was for performance reasons. Or maybe it's different for PCM -> DSD.

[camott]

8 minutes ago, Miska said:

ext3 is steeper while ext2 is gentler. And for PCM -> DSD it is indeed different for the two stage cases in terms of CPU load too.

 

Hires generally has more frequency space at top end for gentler filters. Also ADC side anti-alias filters are typically gentler for hires rates.

 

Right, I do understand the desire/need for sharper/steeper filters for redbook vs hi-res. 

 

So bear with me ... but would the same ext3/ext2 argument apply to gauss-long and gauss-xla filters as well? one might want gauss-xla extra long/steep filter for 1x but could get away with gauss-long for Nx?

[camott]

27 minutes ago, Miska said:

Yes, excatly. That is what I'm having right now on one of my servers.

 

 

Ok. And do you use gauss-long for Nx because it sounds better with the shorter filter or because of performance issues with PCM -> DSD SDM process with gauss-xla? (or put another way, is there a sonic cost for using an unnecessarily long/steep filter on hi-res?).

[camott]

So I got an M1 to do some tests. Somewhat disappointing compared to other benchmarks as @Miska had mentioned.

 

gauss-xla upsampled to 1.536 PCM into null output took 4:46 to process a 4:55 file. No doubt with the overhead of a real DAC attached and some PEQ thrown in and Roon also running in the background, there will be dropouts. Auto/adaptive multicore vs enabled doesn't make a difference on the M1 as there are only 4 power cores to begin with. So the M1 is going back to Apple. Hopefully they soon replace the top-tier intel Mac Mini with an M1X version with at least more power cores - that should allow for auto/adaptive to use 2 more cores and improve the performance a bit, which might be enough to meet my needs. I don't think M2 with faster cores is coming out until next year. Booooo ....

[camott]

17 minutes ago, MikePid said:

It is very stable with DSD256 7ECv2 gauss-long for 1x and just gauss for Nx.

I am running Monterey and this exact same setup also works for me, except that I get dropouts with 192k source content. Using a lighter filter like poly-sinc-short-2s does work for 192k.

 

Can you try your setup with 192k source material and see if it plays without drops? If so, I might try going back to Big Sur.

[camott]

Any chance you could try playing this free demo file from 2L and see it works?? http://www.lindberg.no/hires/test/2L-106/2L-106_stereo_PCM-192k_MAGNIFICAT_04.flac

 

When I run it with DSD256 ECv2 and poly-sinc-gauss on Monterey I get a brief dropout every 10 - 20 seconds.

 

 

[camott]

Just now, MikePid said:

Same results as you - dropouts. Are you using DSD256 at 44k or 48k?  I have to rate covert to 44k.

 

We need settings for 1x, 2x and Nx 🤣.

 

Yes indeed! I get dropouts at both DSD256 44k and 48k. However, I *can* play up to 96k with DSD256 44k but not 48k. Everything is right on the margin here.

[camott]

So now that there are functional linux kernels for the M1, maybe one day @Miskawill build HQP Embedded/OS for the M1 ... :| I know it's early days yet but would be cool to have HQP Embedded take advantage of the M1.

 

 

[camott]

My above observations were done using NAA on HQPlayer OS on a fitlet2. I decided to try using a different NAA endpoint I still use sometimes, an Allo USBridge running RoPieeeXL. I was surprised that all else being equal (eg. attached to same switch, etc, etc), I got the occasional dropout with the Allo USBridge even with 48k source -> DSD256x44.1. This endpoint has never had an issue in general with dropouts, connectivity, etc. Not sure why/how this is happening but it appears that the NAA endpoint is also having an impact on the margins here with DSD256 upsampling on the M1.

 

[camott]

What he means is using another endpoint device for NAA purposes and having the Mac's HQPlayer connected via that instead of directly connected to downstream device/dac.

 

If you aren't concerned about other issues related to endpoint/server separation, what's wrong with DSD over DOP? From my recent testing, the Mac supports DSD256 over DOP in general. The only issue I had was that the slight increase in CPU pushed things a bit more at the margins (eg. dropouts when doing 96k > DSD256 with EC v2 modulators some filters).

[camott]

So I have been playing with various NAA endpoints in combination with an upstream M1 Mac mini running HQP. (and into a Holo May DAC). I have tested 4 device scenarios thoroughly using everyone's recent favorite test case at the margins - 96k -> DSD256x44.1 with ASDMC7ECv2 and poly-sinc-gauss:

 

1. M1 directly into DAC using DSD over DOP: simpler setup but occasional dropouts and other issues (fan, electrical noise) being located next to DAC.

 

2. Allo USBridge NAA using different linux distros, including tweaked kernel on GentooPlayer: no matter what, I could not get rid of the rare occasional dropout with 96k. Just slightly not quite perfect. I think it's an issue with the RPi 3 or ASIX ethernet chip or something hardware related.

 

3. Fanless Intel PC Stick with HQPlayer NAA image on SD card: software is obviously as simple as it gets and works flawlessly at 96k. But the device is too light, requires too many adaptors, and mine doesn't maintain BIOS boot order. Also, running an LPS with most sticks is problematic given the micro-usb connectors, etc. But a GREAT solution if you want cheap and easy.

 

4. Fitlet2 with optical connection and debian server running NAA. This is my favorite setup because:

         a. no dropouts and works flawlessly at 96k

         b. lots of software/os options.

         c. the device is weighty, solid, well designed.

         d. optional optical networking connection allows for isolation of ethernet gremlins for peace of mind. 

         e. works within a large voltage range, has 2.5mm DC input and thus easy to use a basic LPS.

 

So currently I have the M1 -> network switch with optical SFP -> Fitlet2 running Debian server -> DAC.

 

I am using Debian server as I will able to install NAA, RoonBridge, and a Python app that uses Flirc to control upstream Roon/HQP volume, stop/pause/skip using the unused buttons on my Holo May DAC. 

 

Highly recommend the fitlet2 with optical. I am guessing it sounds just as good as a Sonore OpticalRendu for a  quarter of the price and with much more software flexibility. 

[camott]

12 minutes ago, MikePid said:

NAA allows you to bypass CoreAudio.  CoreAudio doesn't know what DSD is, but you can have something like HQPlayer disguise it as PCM using DoP.  You just to make sure your DAC can support a sufficient PCM rate to get the resulting DSD rate you want.  DoP didn't seem to add any processor load, or affect the sound quality for me.  In my case, my DAC only accepts input up to DSD256/PCM756, so DoP limited me to DSD128.

 

Not sure if you tried this or not ... is it possible to install NAA next to HQPD on the same (M1) server and bypass core-audio without a downstream NAA device?? So HQPD on M1 -> NAA on M1 -> DAC?

[camott]

one more thing I like about the Fitlet2 - the 3.5mm audio output has a 4th pin and can support SPDIF with the right cable. So for instance I can run RoonBridge into SPDIF when doing multi-room playback and NAA into USB when doing critical listening.

[camott]

53 minutes ago, Schafheide said:

Is it feasible to wipe MacOS on Mini M1, install Ubuntu 20.04 LTS with latest kernel 5.15. Then install HQPlayer?

Is so can someone explain how they did it?

Because it is Linux, I assume that it will play nativeDSD without the need for a NAA?

 

No. There are some projects working on porting Linux to M1. It's more than just the kernel, it's drivers and firmware and disk management and GPU and T2 security chip, and all sorts of things. I am following this project https://asahilinux.org and one of it's main contributors twitter.com/marcan42, who is simply amazing.They are making huge headway and may have an installable distro available soon. I wouldn't be surprised if they could already release something simple and useable for the Mac Mini that would meet our needs for HQP but they are mainly focussed on getting Linux running on the MacBook's as that is the big use case - and thus lots of work on the integrated keyboard driver, trackpad, etc, etc. So we will have to wait for that to get completed in the next few months.

 

[EDIT: I should clarify that there are a number of options already available that will allow you to run Linux as a VM on the M1 ... but of course that's not what we want]

[camott]

2 minutes ago, Schafheide said:

camott - Have you seen this

https://fedoramagazine.org/contribute-at-the-fedora-linux-36-test-week-for-kernel-5-15/

 

Sorry, no, and what does that have to do with the M1?

[camott]

19 minutes ago, Schafheide said:

https://appleinsider.com/articles/21/06/28/apples-m1-now-supported-by-linux-kernel-in-version-513

 

Ah ok, yes kernel support has been around for a while now. As I said, there's more to it than just the kernel though. That's the easy part.

[camott]

This is a VM via VMware running on MacOS, not native Linux. Hey look, by all means try installing HQP in a Linux VM on Mac OS on the M1 and let us know how it goes ... 

[camott]

16 hours ago, BrownMagic said:

Depends on the DAC you are using. If you are using a Holo May KTE with PLL turned on then there is absolutely no difference. With PLL off you will be able to tell the differences between transports.

 

fyi, PLL is irrelevant for USB connectivity to the Holo May. It's only used for other inputs. That said, I otherwise agree with you ... 

 

12 hours ago, AudioDoctor said:

 

Have you tested this against all the various NAA devices, or are you just assuming?

 

Personally, I have tried a Sonore OpticalRendu, an Allo USBridge, a Fitlet2 via optical, and a fanless Intel stick .... and I have not noticed a difference in SQ over USB. Given the May's excellent USB (galvanic) isolation, I find it difficult to believe those who say they hear differences due *solely* to the hardware used to run NAA.

[camott]

4 minutes ago, AudioDoctor said:

 

I have here at the moment a raspberry Pi4, a Sonore Signature Optical Rendu, and an Aqua LinQ with the NAA module and I can hear the difference between all of them. I modified my DAC to use the i2s input from the LinQ because it sounds the best.

Maybe the Holo DAC is putting its sound onto everything...

 

Sure, this was with respect to the Holo May via USB, which is what I thought you were asking about. Your Sig says you are using a Lampizator DAC? If so, I would fully understand that the NAA hardware would make a difference. I used to have a Lampi and they just use off-the-shelf USB cards (Amanero and now JL Sounds).

[camott]

3 minutes ago, AudioDoctor said:

 

This is laughable.

 

 

 

Sorry how so? I was trying to provide what I thought was a reasoned response. Someone else said the NAA hardware wouldn't make a difference with some DAC's like the Holo May, and you then asked if one has tried different NAA's with it. I provided my actual experience with the May and various NAA endpoints.

 

I don't understand the rudeness. 

 

[camott]

Just now, AudioDoctor said:

 

Rudeness?

 

Your response to my response was "this is laughable". That seems rude.

 

Your profile (not sig) says you use a Lampizator Pacific.