Whilst having a digital expert on call, how do we best manage up/resampling? Like other software players, Audirvana can up/resample to high-rate PCM/DSD with user-selectable algorithms and targets. This leverages the high-speed CPU of an external computer. My DSDAC 1.0 Deluxe resamples all incoming PCM to DSD via FPGA. The target rate can be as high as DSD 1'024. Does Mr. Deng have a preference to resample to that or a lower DSD/PCM rate on the send end; transmit natively then handle the same math on the receive end; or split the difference? One scheme pipes higher-frequency signal through external coaxial or fibre-optic wiring, the other limits itself to circuit traces in a DAC. Is external cabled transmission more prone to jitter? If so, are higher sample rates more or less susceptible?
"I tested this. If you use top-quality upsampler software to rescale music files to DSD512 by PC then play through my DSDAC's non-rising mode, sound quality is better. However, this depends on the performance of your software upsampler. Since a PC's CPU has more processing power than the FPGA inside the DSDAC, it can utilize more complex algorithms. Better performance is expected. It's why the DSDAC has native mode. I often tell users that when playing DSD512/256, they should use the DSDAC's non-rising mode."
Does this imply that the upsampling algorithm's potentially greater sophistication on the send end dominates any potential jitter issues incurred by wired transmission across greater bandwidth?
"Over POW, GLD1.0 transmits data different than S/PDIF so in packets similar to how computers transmit data to hard drive. Our communications-grade fibre-optic module can transmit G-level data over 10km. With that bandwidth specification, transmitting audio data at even extreme sample rates is a piece of cake. There's no need to worry about the quality of POW data transmission. It is currently the most advanced audio data transmission protocol available." [Above, Cen.Grand's 2025 Guangzhou show system.]

At this juncture reader and Lumin owner Michael checked in: "As I read your Cen.Grand GLD1.0 preview, I'm struck by similarities and divergences in the digital streaming space as Lumin just launched their new flagship transport U2X [above – Ed]. Similar to Cen.Grand, they offer a clock input but perhaps better Cen.Grand with the opportunity to synchronize up to two other devices to a master clock, either their internal OCXO clock or an external clock. Where Lumin diverge from Cen.Grand is with a newly developed isolated USB output that negates previous issues with that protocol's jitter susceptibility. The Lumin also incorporates a separate linear power supply and features its now traditional dual Ethernet connections: RJ45 and fibre. One day it would be fun to compare the two though the ~€11K ask of the Lumin will be well north of the Cen.Grand. For now however I wanted to alert you to the evolving competitive landscape although I suspect you are quite aware!"
Michael's error was misreading POW's BNC socket for a clock input. Like external I²S, it's a discrete bit-clock output not meant for any external clock. Also, Cen.Grand's PCIe interface eliminates USB-based data processing past the input stage if we use network-attached storage. If we don't, there's no USB at all. For PCIe Cen.Grand invoke not merely zero jitter but no USB-related software layers of drivers, buffers and OS. Where Cen.Grand offer POW and I²S/HDMI, Lumin's solitary output beyond PCM192 and DSD64 is USB. Finally, Cen.Grand don't believe that external clocks for LANcillaries like network switches have any benefits whilst their own DAC architecture disregards clock quality. Hence they skip the clock-upgrade topic entirely. Divergences. These seem best suited to a friendly soccer match between teams Lumin and Cen.Grand. Whoever the referee, should he grant foregone goals to Cen.Grand's cover-art display, HDMI out to a big external screen and a stripped-down Windows OS for user-installable ASIO-capable software players instead of a closed ecosystem? Choices. They can be grand and gobbledygook.
If we're IT lightweights, here's more gobbledygook: "PCIe is a serial protocol which gives each device its own dedicated connection to the motherboard to eliminate bandwidth contention between parallel devices. Multi-lane support up to x 16 expands transfer bandwidth where the top 5.0 spec is 32GT/s. Common interfaces for PCIe are graphics cards for faster video/gaming processing; SSD particularly with the NVMe protocol; network and sound cards; and storage controllers." In layman's lingo, might we perhaps imagine that for Cen.Grand's application, PCIe above and beyond extreme speeds delivers hog mode to prevent shared processing resources for audio-data transmission? Audirvana's hog mode disables background threads so that the CPU of the device it's installed on focuses all its computing resources on the audio task at hand. For an IT layman like myself, the hog-mode descriptor suggests more targeted operation than a USB tree that multi-tasks between numerous computer peripherals via layers of management software. In Mr. Deng's adoption of the high-speed PCIe protocol, the direct connection between device and motherboard via elimination of intermediary drivers and OS seems key. At this juncture, HifiStatement's Lumin U2X review hit. Here's the pertinent quote: "The SOtM clock which had also reclocked the Melco NAS during the first attempt and at least theoretically might have an advantage over Lumin's own internal 10MHz clock now was solely responsible to clock the U2X. The change of master clocks again had no clear perceptible effect… In my opinion, the subtle changes in sound were not quality differences. Hence to me it makes no sense to invest in an external 10MHz clock plus high-quality power supply. That relativizes the price of the U2X considerably when SOtM's external clock without power supply currently lists for over €4'500."
Trinity studio-grade masterclock by Antelope Audio, ~$3'400.
We recall how external masterclocks arrived from recording/mastering studios where multiple parallel digital workstations get sync'd to a shared masterclock. This gets critical in audio-for-video post production where a specific integer number of samples must be in every picture-frame period. This requires syncing the audio sample rate to the picture frame rate. In audiophilia, the need to sync parallel digital devices is very rare. Now advocates for masterclocks shift from synchronization needs to the pursuit of improving the quality of clocks from internal to external. For home use, digital luminaries like Ed Meitner consider that faulty thinking and call the best clock the one nearest the DAC; internal and separated by just short circuit traces. We're back at divergence, choices and potential gobbledygook. When even proper digital engineers can't agree, my techno-peasant brain opts out to let my ears decide. Wherever they can't, simplicity overrules complexity for fewer boxes, fewer cables and lower outlay. With Gold's pure transport profile relying on an external DAC to mean two boxes, cancelling the topic of external clocks and their power supplies is to my mind a real bonus feature.