Initially I had the sonicT i7 running both RoonServer and HQP Embedded but this weekend when visiting the old man, I setup RoonServer on ROCK NUC i7, to separate RoonServer from HQP Embedded on the one machine - to minimise CPU usage on the sonicT i7 to a minimum.
But there were still pops at DSD512. The attached file is the song that shows pops in the first 40 seconds. For testing with pops at DSD512 I test the ASDM7 modulator with poly-sinc-short-mp-2s
Connection speed tests between switches is ~880mpbs, so pretty close to the gigabit ratings of the switches and BJC Cat 6 ethernet cable.
I then brought the sonicT i7 from the home study/office, into the listening room to connect it via USB directly to the Pro-Ject S2 DAC. This would by-pass the network switches after HQP Embedded and by-pass the ultraRendu/NAA completely. But even with choosing ALSA audio backend, I was unable to play DSD to the DAC. It would revert to PCM every time.
Has the sonicTransporter got the same Pro-Ject S2 DAC drivers as the ultraRendu? We donāt want the sonicT i7 in the listening room anyway but just for this test, I was unable to test at DSD at any sample rate.
I have also tried adjusted headroom with HQP Embedded, even down to -30dB. Still pops at DSD512. Weāre only trying to get the 2s variants working at DSD512.
Roon DSD512 up-sampling has been working pop free for 6 months.
There is another user having issues with HQP DSD512 and an ultraRendu in the chain - I wonder if thatās the common thing?
Not sure why I didnāt think of this test myself earlier, suggested by Jussi today.
I enabled Roon DSD512 up-sampling and set HQP to āDirect SDMā - I changed HQP settings to xtr filter (NON 2s) and deliberately set it to DSD256, just to convince myself that HQP was essentially in pass-through mode to the ultraRendu NAA.
With Roon up-sampling to DSD512 (via ROCK NUC i7) , the Pro-Ject S2 DAC indeed showed DSD512 on the display and the sonicT i7 (running only HQP Embedded and nothing else) showed CPU usage 0% (as it should, with HQP essentially in DSD512 pass-through mode).
No pops with the above config!
So itās not a network issue, not a NAA issue, not a sample rate issue. The only variable is Roon DSD512 up-sampling (no pops) vs HQP DSD 512 (pops), both going through HQP and NAA.
Thoughts? Are we now back to a sonicT i7 CPU loading issue?
This points me towards the ultraRendu/NAA, which seems contrary to your ādiscoveryā.
(However I donāt know if your logic is correct in that what you have changed is that HQP is not upsampling, so the issue could still be HQP upsampling OR a CPU issue surely?).
By selecting the xtr filter (deliberately the NON 2s variant) and seeing CPU usage was 0%, this is proof HQP was not up-sampling and was in pass-through mode.
There is no chance my i7 or yours or @andybobās can cope with this filter (non 2s variant) at DSD512 - 0% chance, just like the 0% average CPU usage I was seeing during playback.
Did you ever uninstall and reinstall HQPlayerd on the sonicTransporter? Jussi made a lot of fixes for this problem but you need to reinstall to get them.
For anybody else reading this this is only for people who install HQPlayer d before the fixes. Now you get everything when you install HQPlayer Embedded from the package manager.
Yes I did that this weekend before doing testing. Deleted HQP Embedded and NAA from the ultraRendu to start from scratch.
I had done previously as well, when you advised of previous updates, i.e. fresh installs from scratch.
Still get pops at DSD512.
And this is with the sonicT i7 only doing HQP Embedded work - RoonServer is running on a seperate machine. Until I can get DSD512 working without pops, Iāll keep Roon Core separate on the ROCK NUC i7.
If we can get that config pop free, Iāll then re-try with RoonServer and HQP Embedded both running on the sonicTransporter i7.
Is there anything else installed/running on the sonicTransporter than HQPE? Roon Core (even if not in use=? Could you use the Backup-feature in the web interface and send me your configuration file over email?
If you have a spare NUC/laptop or other PC/Mac hardware, you could try booting my NAA image from USB memory stick and see if it makes a difference compared to ultraRendu.
Nothing else on the sonicT i7, only HQP embedded. As mentioned above, I have moved RoonServer to a ROCK NUCi7, to give HQP Embedded full resources of the sonicT i7. I would prefer to have both run on the sonicT i7 since Andrew and Jesus said it can run both at DSD512 but for now, letās see if we can get it working with Roon Core separated.
I will screen share with the old man tonight/tomorrow and send you the backup file.
When I saw Sloop_John_Bās comment about a NUC running NAA working without pops, I realised I missed an opportunity to test my Macbook as NAA when I visited the old man this weekend - Iāve since flown back home and he wouldnāt have the patiece to move his iMac from the home study/office over into the listening room to test this.
So for now I canāt test this unfortunately. I can only test stuff where I can control his iMac and sonicT i7 (which are both far from the listening room) via TeamView.
With HQP, at any one time, only 4 of the 8 virtual cores are being used and the other 4 cores stay on 0% at any one time.
See attached. I watched this for a good 10 minutes, changing albums etc. Press on the images to see the full expanded image.
Iām not an expert in this area, but thinking out loud, I would have though itās better to have all 8 cores working, so that the average loading for each core is in the 35% region, instead of half the cores working at 70% each ?
That is then working exactly as designed. CPUās with HyperThreading expose twice as many virtual cores as there are physical cores. However, those virtual siblings donāt really help HQPlayer, using those would only increase context switching but not benefit processing because they cannot do any computational work. So only real physical cores are used and virtual siblings are left to help OS with context switching to other tasks.
Yes. I just re-installed it on the sonicT i7 just now, only to look at Roonās CPU loading when up-sampling to DSD512.
Ah damn - I thought this was problem solved. If only it was that easy right. Anyway thatās an obvious difference I could see with Roon and thought Iād share that observation.
I assume a max individual core loading of up to 80% is fine then and wouldnāt be the cause of pops when up-sampling to DSD512? This ~80% is what I can see with the system status app, based how often this app reports things - I wonder if in real-time some cores are actually reaching 100%, causing the pops?
Iām not sure what else there is left to try at our end
Do you have any other ideas or are we at a road-block ?
Yeah, because figuring out the real physical CPU topology (sockets and physical cores) is not very simple, many applications donāt bother doing it and just slam the work on all cores the OS exposes in simple terms.
Could beā¦ Checking out the core temps could also be useful. If it runs into thermal throttling that will lower the speed too. But 80% is quite a bit of load for 2s filter, so Iād like to see the config file if there is something extra enabled there.
You can check out with some lighter filter like poly-sinc-shrt-lp-2s and compare if it makes difference to heavier ones like xtr-lp-2s.
Iāve emailed you the config backup file. The only thing that changed after our testing at DSD512 was to change back to DSD256x48 and enable auto family rate for the mqa-mp filter (dad likes that for whatever reasons).
As you will see, startup volume is -20dB, and DirectSDM is not disabled. Thereās not much else that I can change in the config page (probably a good thing - less things can go wrong).
I donāt know how to look at real-time CPU data log or core temps. Can you discuss with @agillis how to get this data?
As per most of the earlier posts, this is the filter that has been causing issues (poly-sinc-short-mp-2s and lp).
Iāll only try xtr-lp-2s once poly-shinc-short-mp-2s works pop free at DSD512 - baby steps.
Edit: to be clear, none of the filters work at DSD512. The goal from the start of this thread is to first try to get the lighter filters to work at DSD512, like poly-sinc-shrt-mp-2s
Just for completeness, it turned out the sonicTransporter i7 (i7-7700) running Roon Server + HQP Embedded was never the issue.
It was an issue with the Renduās at DSD512 with HQP (fine with Roon) - but an update released today via sonicOrbiter OS has fixed the issue at this end.
Tested with a Pro-Ject S2 DAC and iFi DSD Black Labelm, the combination of sonicTransporter i7 + Roon + HQPE + Renduās is tremendous value.
Thank you for the first class support @jussi_laako and @agillis . True gentlemen and scholars.
I havenāt asked the old man (dad) to test xtr non-2s yet. Iāve tested at my end (not with xtr but all others) and didnāt hear a big enough difference between 2s and non-2s to want to work the CPU cores that much harder - call it a quick and dirty mini cost/benefit analysis.
But Iāll ask the old man to test this weekend, just to give another datapoint, in case people are interested.
Maybe when the i9-9900 can do the xtr non-2s filter very comfortably, Iāll do non-2s myself.