Holo Audio Cyan 2

I was mostly right the first time, DSD256puts about a 20% total CPU load, DSD512 puts about about a 60% total CPU load, though a couple of cores are near maxed. It takes DSD1024 to bring the computer to its knees (playback starts stuttering) Tested with 44.1 PCM > DSD256 via poly-sinc-gauss-long & ASDM7ECv3

 

Thanks for the heads up. I wonder if this will have any effect on HQP/Ubuntu losing the USB connection (not sure which is responsible - don't think it's hardware as my Windows box stays connected to the Cyan via USB just fine) however but will upgrade anyways

@dericchan1 , just so I'm not missing anything, there is nothing to configure around this "signal correction" feature in 5.7.0? I upgraded but the interface is exactly the same (no additional config) unless I am missing it...

 

How much cooling? My i9-11900 also shows around 20% total CPU load for DSD256, but a couple of the cores get a bit too hot for comfort, even in a fairly aggressive cooling schedule.

 

Nothing to configure. The program detects whether you have a suitable dac that the improvements can be applied to. You need to go into the matrix pipeline menu, at the bottom, you will see the correction box and a drop down menu. Select the holo cyan 2, click enable.

I don’t know if you also need to enable at the top left of the menu but I did. After that, click ok and start playing, but it will take like 30 seconds or so to load the correction settings

 

It is passive, fins & pipes (which connect to the case I think?), forget the name...would have to dig up invoice...Case is covered in fins and is nice and toasty to the touch, but I can leave my hand on it.

Good question on the core temp, monitoring sensors under DSD256 load indicates an average of 55-60 C, with peaks of 70 C, though core 0 will peak at 80 C occasionally. Is this worrisome levels? Quick Googling indicates Intel chips will throttle at 100 C.

Yep, have to "enable" at top left. Overall CPU load is now at least 50%, with two cores at 70%. Core temp is up of course, now averaging 65-70 C, though not peaking past 80 C.

Any idea what these "corrections" are doing? I can't say I hear a difference in a short A/B, though perhaps extended listening might reveal something... Think I will leave this off until I get a grip on the advantages.

Did Jessi explain the corrections on a HF or Audiophile Style post somewhere?

 

In my experience, running few intel animation workstations and a renderfarm, 80C is just fine. All the online handwringing about keeping things to 60 or 70 is just nervosa. All these new chips run hot AF. Throttling doesn't happen until 100C. I personally try to keep things below 90 when rendering as that keeps me well away from throttling. The intel chips will run fine for years and years with this level of usage. My last batch of machines ran like this for 4-5 years quite heavily. I had no CPU or motherboard failures.

 

I don’t expect Jussi will be telling people his proprietary work so others can come up with HQ1player or something but he basically said he analyzed the flow and pattern from digital input to analog output signal performance of these 10 dacs and managed to find corrections to improve their output signal performance.

Both myself and my friend who owns a spring 3 kte heard the improvements. I have not been able to spend too much time on the cyan 2 as I just bought another dac (Signalyst dsc2) yesterday.

But yes, it just sounds like imaging more precised, more like all the pieces are tied together better - coherency. They're not as spread out and completely unlinked. Like all the instruments are more believably located in the same space.

 

That looks very good! I'd really love to have more details on your box, as it seems to be doing way better than my current one, which gets close to or to thermal throttling occasionally.

BTW, my other system, with a Mac Mini M1, is running at 60-65% for DSD256 with the Spring 2 corrections on HQP Desktop 5.7.0. The M1 seems not to break a sweat at that constant load. The corrections seem to add a bit more space and tonal density, but maybe that's placebo.

 

I've found the biggest culprit of CPU heat is turbo, so if you're offloading the filter to CUDA, you might try reducing your max turbo clock and seeing if you can still run the shaper - it could drastically reduce your CPU temps.

On my 13900h there is more than enough headroom to run ASDM7EC-Super 512+fs at the stock clock - no turbo at all at DSD 256 which is max my DAC will support. I know this is not a good match per se, but I wanted to test with an aggressive shaper to illustrate this point. The filter is offloaded to the mobile RTX4070, so all the CPU is dealing with is the shaper.

Running with Turbo off, CPU Package temps sit at about 52 deg C.

With Turbo on, temps immediately rocket to 68 deg C in the above scenario. The workload has not changed, simply how aggressively the CPU is responding to the workload and that creates heat. The shaper does not spike the CPU and isn't 'choppy', so Turbo clock speeds in my case are simply not needed to run the shaper properly. So I disable Turbo and save myself 17 degrees.

I'm not on a K SKU so I can't mess directly with the clocks, but it's easy to turn off turbo or throttle the wattage in Intel XTU or simply with Windows Power Management by setting max CPU to 99%. Not sure what Linux offers in that vein though, but the BIOS may have settings exposed as well even on a laptop. If you have a desktop K SKU you can tune this to your heart's content of course.

 

I ordered from this outfit in England because every American builder I found (online or local) wanted another 40% (though I spent only so much time in the price hunt), so even with shipping I "saved" a few hundred bucks:

https://www.quietpc.com

They were easy to work with, clearly communicated, and the packaging/instructions that arrived with hardware was clear enough I would allow them to ship to my tech noobie family members

This was my build:

Quiet PC Euler Fanless i17
- Euler T Plus Fanless Thin Mini-ITX Case
- PRO H610T D4-CSM LGA1700 Thin Mini ITX Motherboard (DDR4)
- 14th Gen Core i3 14100T 2.7GHz 4C/8T 35W 5MB Raptor Lake CPU
- Corsair Vengeance 16GB (2x8GB) DDR4 SODIMM Memory
- NT-H2 Pro-Grade Thermal Paste, 3.5g
- 120W Thin mini-ITX power adapter, AK-PD120-04M
- No mains cord needed, I will supply my own
- Solidigm P41 Plus 2TB PCIe 4.0 M.2 NVMe SSD (4125/3325)
- Free Silver Warranty (2 years labour and parts)


After reading about the efficiency of the Mac M1 chip, I seriously considered going with a fanless Macbook Air, but decided my wife/kids would be too tempted to requisition a nice laptop for their own purposes This headless box just looks like another audio box to them

So I think I have tracked down the source(s) of HQPlayer (and Roon for that matter) losing USB lock to Cyan: running Ubuntu headless. When I log in remotely (VNC or rdp via Windows native rdp client or any other client) Ubuntu switches sound settings to send sound to remote client. Combine this with Cyan's auto-magic input switching and throw in Linux also trying to manage displays and send sound to them (my monitor is HDMI, but I'm using one of those dummy VGA emulators in the DisplayPort) and Linux is just confused and I can't find a methodology to help it keep it all straight.

Anyone know of an app (preferably with a graphical interface - I'm no shell wizard) I can run in Ubuntu to take charge of ALSA and force it to keep locked unto the Cyan (USB) no matter the display/remote login state?

Or...perhaps I should load HQ NAA image on my Pi Mercury and connect to the Cyan via I2S and/or USB...

Update: Turns out RopieeXL which I'm running on Mercury has HQP NAA endpoint built in, so now running Linux/Roon > HQPlayer desktop > Pi Mercury (RopieeXL set to not power manage) > Cyan via USB. This should get around my Linux sound setting issues when running headless, I think, will report back. USB from Mercury sounds good, no obvious issues/differences here in the first 10 minutes at least...

 

I2S from Mercury will be much better than usb. It is what it was designed for.

 

I will be using I2S for PCM - out of the Mercury it is butter smooth. I need the USB for PCM>DSD conversion (DoP transport method for Cyan) from the compute board because the HAT (or your name for the I2S circuit inside Mercury) is limited to 192mhz. I have v1 of the Mercury - the SBAF version.

Does your latest Mercury (v3 I believe) have a higher limitation, possibly allow Dop for DSD (or just higher PCM rates)?!

 

Thanks, I've used them for my first fanless Roon server, same good prices and service.

Thanks, I'll investigate!

I run my servers headless, but with Ubuntu Server rather than Ubuntu Desktop. I use Cockpit to manage them remotely. I don't think Ubuntu Server will have the problem.

 

Mercury does support DSD over PCM. I know that in volumio you simply have to enable it in the settings. But it does require that your DAC supports it as well. You are still limited to 192 kHz, which I believe is DSD64?