It doesn’t matter to me as I prefer the sound without.
However, I am sure this is a fault.
I am listening to DSD128 files via Grado Gs1000e headphones. If I enable crossfeed, the music stops for quite a few seconds and then starts up again exactly where it stopped.
I am usin g a Micro Rendu. It matters not if I am using as HQPlayer NAA or Roon Ready. The same thing happens. Roon gives a message saying the track might be loading slowly which seems unlikely.
I don’t acre as I do not like the sound with Crossfeed enabled. However others might and so I thought I’d let you know of this weird happening.
Oh and the CPU is 80% idle when not using this setting but it doesn’t use. much more when using it-over 70% idle.
As are most settings I choose when using HQPlayer as my zone. Even ext and xtr don 't over tax the machine tho I do not like the sound. I am no longer concerned about using a Mac Book Pro as my core.
I have turned all of my Carly Simon albums into DSD 128 (backing up in two different drives the original .AIFF or .FLAC files. I think I shall do this with all my records. The sound is good, I have 2-3 copies of the originals, hardly any CPU usage when playing DSD files although it take an enormous amount of the CPU, almost 100% to make the DSD files. I use dB Converter. Is the amount of CPU needed to do this normal or could different program use less cpu?
As well as enjoying the sound of these files, the CPU usage when playing them hovers around 78% idle. The fan has yet to come on.
One final thing, anyone know of a cd ripper to HDD or preferably SSD, available in the UK or EU which isn’t also a server etc. The only reason I want somethin g like is that recording the way I do now is slow and is going to take weeks wo re-do my cd collection. Not because of the player or the MBPro but because of my disability. I think using something like a cd ripper to storage would save me a whole of trouble,. I need to do it because during the period a head bang sent me off the planet for 5 years, I now find I recorded ma ny in MP3. I still can’r believe I did that but then I also find it hard to believe I lost almost 5 years of my life even though I have photographs to prove I was still alive and living a life of sorts.
Yesterday I had this same behavior start with a Logitech Squeezebox Touch connected via WiFi to Roon Rock. I’ll try disabling Crossfeed and see if that clears things up. I hadn’t used the Touch for 4 or 5 days until yesterday so I can’t say exactly when the behavior started.
Are you monitoring all cores. When using HQP I was confused as ASDM7EC wasn’t working and task manager showed the CPU at 30% load.
However, when I opened it up to show all activity 4 cores were fully loaded which is the most HQP uses. The other 12 cores were only lightly loaded so task manager was showing the average load across all cores.
But because HQP only uses 4 cores max it had hit the headroom of what it could utilise and thus playback kept pausing as you describe.
I also assume you are doing some form of upsampling unless you’re playing native DSD128 files?
Clearly I was not as clear as I thought in my first post.
I am NOT upsampling.
It makes no difference whether I am playing PCM or DSD128 files(NOT upsampling-the files are DSD 128). Oh, except HQP automatically upgrades all PCM to 384. Even so, that is not what accounts for the stop/start.
This behaviour only happens when I use headphones and was choosing crossfeed merely because it stated that crossfeed was to make the cans sound more like speakers. This made no sense to me, I did it assuming the techs knew better, and they do, but I hated the sound and as I said it kept stopping, playing, stopping.
My Mac Activity Monitor is accurate. No more than 25% of the CPU was being used.
When I am changing files from .aiff or .flac to DSD my CPU is almost 100%! When I allow HQP to do the coding to DSD128 as it is playing, the CPU i still 70% or more idle.
Even when choosing ext or xtr in HQP, the CPU is still mostly idle.
As per my previous post you can see that my overall cpu load is only 34% but HQP is maxing out the cores it is able to utilise. Unless you view all cores as Jussi mentions it is impossible to know the load HQP is putting on individual cores in your system.
See this post and the next few for a brief overview of the reasoning behind this.
I think I found what you are showing me on your windows. I can just about see what is inside the circles you have drawn and I see a wiggle topped box almost at the top of the boxes.
As you can see from this screenshot of the relevant bit, none of the cores are anywhere near fully taxed. They were as soon as I opened Chrome to send this to you. However after some initial farting about with the meters in each column going up and down, to the top, and down again, it all settled and am now listening on headphones with Crossfeed enabled and it is playing as it should and it is converting to DSD128 from FLAC 44.1kHz 16 bit as it goes.
I have now turned the Crossfeed off, and the columns all fell by a single strip.
I forgot that it says that overall the CPU is 70-75% idle, the system uses almost 4% and I use the rest.
It seems I was too hasty to switch it off the first time it stopped and started and stopped the first time. I was just afraid something was going to hurt my gear. I am not a techy. I can do enough for my needs and I learn.
I had no idea at all where to find my equivalent of the chart you posted, but I did find it.
Because as I have mentioned that is the average load over all cores however if you start doing anything heavy with HQP your CPU load will still look low but the actual cores it is using may be totally maxed out.
And to be fair, if you are not upsampling with HQP and just using it as a native player you are not really benefitting from what it can do. So, for example if your files are DSD128 and you are using HQP to play at DSD28 it’s just a bit of a superfluous software in the chain.
Knowing how HQP loads the processor is key to understanding when it is overloaded or when there is a genuine fault with HQP. Again I refer you to my screenshots - my CPU load is showing as 34% yet there is very little extra processing headroom left for HQP to do much else than what I am asking it to as the 4 cores it can use are nearly saturated.
Even if I ask it to do ASDM7EC @ DSD512 the overall CPU load stays around 38% so in theory that’s 60% idle yet there is no processor currently capable of upsampling to that so it doesn’t work. If I only looked at the overall CPU usage I would be led to believe there was a fault with HQP when in fact it is simply a lack of processing power.
So to demonstrate; I have set HQP to run poly-sinc-ext2, ASDM7EC and DSD51. This does not work - exactly the symptoms you describe - play a bit, pause, pick up from where it left off etc.
Looking at the overall CPU load though it is only around 35% so why isn’t it working? I’ve got bags of processing power spare, it’s 65% idle so there must be a fault with HQP surely? But no - look at the individual cores and you can see 4 are maxed out. So you cannot rely on the headline CPU figure as it is not an accurate representation of the the load HQP is putting on the cores it does use.
I knew what you meant the first time. But your graphs mean nothing to me because I use a Mac. Where would I find it on a MBPro?
I just deleted the rest of this post because I decided to call Apple and the tech guy told me that the graph I posted does show the core usage.
Just to be certain I then googled how do I get the core usage info on the MBPro. The answer is the same. On the several links and two YT videos I watched.
So whatever the reason for the odd behaviour when choosing Crossfeed when using headphones, it isn’t the cores getting overloaded. However, as I said, the behaviour stopped. In the end I prefer to listen to my cans without Crossfeed.
I would seem that MBPro and probably Windows, high end, laptops are more than capable of running HQP. One doesn’t need to be able to use every option.
We like the options chosen but for fun I am going to fart about with other options and see what happens.
Yeah, not horribly much spare on the physical cores. Note that cores 2, 4, 6 and 8 are virtual siblings of 1, 3, 5 and 7 and not used for heavy tasks because they don’t have independent execution units.