|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
206.255.213.61
In Reply to: RE: Roon & HQPlayer on my Mac, Any HQPlayer tips? posted by AbeCollins on July 06, 2016 at 00:41:38
as another IT guy trying to put your numbers into perspective:
1. Do you know which 2.6 Ghz model i7 you have? There appear to be about half a dozen Intel flavors.
2. Are those utilization figures real time or just percent of tasks run?
For comparison purposes, my i7-860 stays under 1% real time usage with LMS and one music stream including a FLAC decompression process along with Win7 Task Manager itself. Increasing that to two separate streams for a second player adds one more FLAC process and increases usage to occasionally bumping 1%.
If music player software consumes about 12% of a very capable processor - like a quad core i7, I can understand the concern of those about compromised performance using relatively weak ARM units.
Follow Ups:
1. Do you know which 2.6 Ghz model i7 you have?My Mac Mini has the Quad-Core 2.6GHz i7-3720QM, Turbo Boost up to 3.6 GHz shown in the middle column below.
I think your processor is a few years older listed to the far left. The one to the far right was the standard offering by Apple. I paid a little more for the optional higher speed version shown in the middle column.2. Are those utilization figures real time or just percent of tasks run?
The % CPU column in the Mac OS X Activity Monitor shows the percentage of CPU capability used by each process. I think you would call it real-time as the figure fluctuates as the process changes load on the CPU. However, as with any such tool there's a sampling period and the tool itself consumes some CPU resources. I don't know what that sampling period is. There's a link below with a detailed description of Activity Monitor.
Keep in mind that Roon Core and HQPlayer can be somewhat processor intensive and I'm running both on the same Mac then USB straight out to the DAC.
Another scenario (which I will play with again) would be to run a separate networked 'end-point'(NAA) like a microRendu or a DIY Raspberry Pi. These can run the much lighter weight Roon Bridge software or the HQPlayer networkaudiod daemon.
I played with full blown Roon Core on a Mac Mini 'server' and the same Roon Core on another Mac Mini networked 'end point'. It works great but Roon Core on the 'end point' was the same resource hog as it was on the 'server'. I later installed Roon Bridge on the 'end point' Mini and resource utilization was much lower, as it should be.
So for the server side you probably don't want to be running a low powered NAS, Atom, or Celeron class processor stripped of RAM (which many NAS use). However, there are a few QNAP and Synlogy NAS out there with heftier processors and more RAM that will directly support the server side Linux binaries.
If music player software consumes about 12% of a very capable processor - like a quad core i7, I can understand the concern of those about compromised performance using relatively weak ARM units.
True. But as mentioned above, one would run the much lighter weight software like Roon Bridge or the HQPlayer networkaudiod daemon on these networked 'end-point' devices.
Edits: 07/06/16 07/06/16 07/06/16
I'm trying to reconcile the difference between the sum of the upper chart in terms of CPU% (~26%) vs the total system and user time found below in the CPU Load section (~4%). I think the Windows perspective is the lower chart since idle time is always a component.
You have a newer i7 than I with even more grunt!
But as mentioned above, one would run the much lighter weight software like Roon Bridge or the HQPlayer networkaudiod daemon on these networked 'end-point' devices.
I trust that allows the server to perform decompression and upconverting tasks so that the end point is not having to perform any "calculations".
Good eye! I'm not sure how to reconcile the bottom graph with all of the running processes in the top part of the tool. It -might- be a load average over time.CPU Load: The percentage of CPU capability currently used by all System and User processes. The graph moves from right to left and updates at the intervals set in View > Update Frequency.
I haven't played with the "Update Frequency".
Also, I'm not clear on what constitutes a "CPU" for Activity Monitor. Is it a thread? Is it a core? Is it the whole CPU? I'm thinking the whole CPU but different tools define a "CPU" differently and it can get a little confusing with modern multi-core multi-threaded CPUs. I've been using Activity Monitor mostly for relative comparisons.
Yes, it's my understanding that the server side is doing all the heavy lifting with decompression and sample rate conversions as well as DSP/filtering. Hence, the need for a decently robust system or a capable NAS (for those who want to run the software on the NAS). But keep in mind most of us are playing around with 2-channels while HQPlayer can handle multichannel including 7.1 for HT.
The software running on the networked end-point is much lighter weight with much lower processor requirements.
In my present setup, I'm doing all the heavy processing AND playback on the same system.
Edits: 07/06/16 07/06/16
Also, I'm not clear on what constitutes a "CPU" for Activity Monitor.
With Win7, it is for each "logical processor" which would be eight for our units. I also have a Win10 box with an i7-4810MQ with a more modern looking single presentation. My guess is that is the case with OS-X.
BTW, I have one application capable of slamming all eight to 100% for extended periods of time - Handbrake. I use it to convert raw movie files into MP4 versions for streaming via Roku or placing on tablets.
Upsampling PCM to PCM seems to be fairly easy on CPU resources.
I was playing with HQPlayer converting PCM to DSD in realtime. Here's where CPU power appears to come into play. Oh and BTW, it sounds incredible!
- Realtime conversion of a 16/44.1 ALAC* PCM file to DSD64 jumped CPU utilization to 35% steady during playback.
- Realtime conversion of a 24/96 AIFF* PCM file to DSD64 jumped CPU utilization to 47% steady during playback.
- Realtime conversion of the same 24/96 AIFF* PCM file to DSD128 jumped CPU utilization to 77% steady during playback.
*ALAC Apple Lossless Audio Codec ripped from a CD, very similar to FLAC. AIFF is uncompressed similar to WAV.
24/96 AIFF PCM conversion to DSD128
Thanks for running the trials.
So, high resolution PCM sounds "better" when transcoded to DSD?
Well, the whole Roon + HQPlayer setup sounds outstanding, even running on the 'server' alone direct to USB DAC (no networked end-point).
I haven't done a serious sit down eyes closed strain my brain critical listening session but even straight PCM sounds great. PCM to DSD was sounding really sweet while I had it playing. I'm still messing with various parameters and will do the serious listening later.
I'm pleased so far.
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: