I note that in the manual for the Vivaldi Clock (p. 10) is a discussion “Using sources that cannot lock to Word Clock”. My setup includes the APEX DAC, Upsampler, and Clock. I’m using 3 pairs of clock cables for this stack (I’ve no dCS Transport).
I have a Grimm MU1 player without a word clock input. It is connected to the Upsampler via an AES/EBU cable. And it only works successfully if I set the sync mode for both the DAC and Upsampler to Audio.
My central question is whether following this instruction is at all beneficial in my configuration?
“Next, connect a BNC cable from the Upsampler’s Word Clock Output to the DAC’s Word Clock In3 input. Connect one of the Upsampler’s SPDIF outputs to the DAC’s matching input, select that input and set the DAC’s Settings > Sync Mode page to Word Clock 3. Set the Upsampler’s Output sample rate and play the music. To change between the un-clocked device and the Vivaldi Transport (for example, select the relevant inputs on the Upsampler AND the DAC.”
Am I losing anything sonically by failing to follow this approach?
The streamer is just an audio source like other media with varying sample rates but with the majority of music files at the standard CD rate of 16 /44.1. So the reason for upsampling streams is the same as CD or locally stored files if your tastes are inclined that way.
Or is the question more specifically addressed to Vivaldi where the upsampler is also a streamer thus creating duplication?
Or is the question more specifically addressed to Vivaldi where the upsampler is also a streamer thus creating duplication?
Yes - that was my point Pete. The upsampler is a streamer, why would one need two?
I thought how does the community here use dCS- as a “DAC” or as a “streamer”?
My guess is that the majority uses streaming (either upsampler with Vivaldi or build in like Rossini).
Guess this is what happens when I elaborate on my hardware environment. Should have just left it all about the Clock. Hopefully someone from dCS will see my original topic header and explain the specifics for use of Word Clock 3.
Seems it’s designed for the case where a source cannot accept externally provided clocking, yet seemingly will be offered the option to use W3: “Word Clock 3 – The DAC locks to an external clock connected to Word Clock In3” for that specific source.
Today my Grimm MU1 is seen by the Upsampler and DAC and requires that I set the “Sync Mode” for both as “Audio”. I’m guessing that since I’m wired to the Upsampler via AES/EBU (it is the only output offered on the MU1 other than a single RCA S/PDIF) that allows this to work, whereas I find the following statement in the DAC manual: “The SDIF-2 and USB inputs cannot be set to Audio Sync.”
My Grimm MU1 is acting today as a Roon endpoint (with Roon Ready certification still in the works). Rather than using the MU1’s Roon Server, I’ve opted to run that on a MacMini M1 system. Reason: better performance by offloading this to a far faster processor (MU1 is running an Intel i3 and Tiny Linux with 8GB memory) for my quite large database of songs (well over 100k). FYI: I do not use any Roon DSP or anything else in the Roon Server that would hamper SQ.
A side benefit (which I cannot explain) is seemingly better SQ. This might be due to the Roon on macOS implementation (Apple’s OS, though based on Linux, is tailored to their hardware). And it may be the case that Roon has worked with Apple on their implementation.
Using AES/EBU out of the MU1 is recommended by Grimm for best sonic results. The real magic happens in the FPGA of the Grimm. Leaps and bounds better than all my prior streamers running Roon. I am awaiting their upcoming support for DLNA/UPnP to test out JPLAY.
Technically, following the setup instructions in the manual will give you better sound.
The issue with setting both your Upsampler and DAC to “Audio” Sync is that both are then reconstituting their Clocks based on retrieving a clock from the incoming AES stream instead of from a single clock source.
If you follow the manual, while the Upsampler reconstructs its clock from on the incoming AES from the MU1, but it then supplies its stable Clock externally to the DAC, which is better than letting the DAC reconstruct its clock from it’s incoming AES.
Yikes, thats heresy! MacOS is most definitely not based on Linux!! It’s based on NeXTStep which has a Mach kernel; very very different from Linux’s kernel (although they’re both Unix derivatives).
I’ll await an official response from dCS on the clocking question.
Sorry for my OS mixup. Linus Torvalds developed LINUX as a free alternative of UNIX in 1991, since earlier distros were licensed tech from a variety of sources including UC Berkeley’s BSD and DEC.
You’d think I’d remember the “genealogy” of OS’s, having worked for IBM and supporting their BSD flavor of UNIX. But at the same time I was working on Intel based options, including LINUX. Very confusing times.
The acquisition of the UNIX-like NeXTSTEP, built on the MACH kernel (from CMU) along with some FreeBSD code, etc. Apple was to use this for their NeXT computer hardware. I think it eventually was called OPENSTEP. All of this led to Mac OS X as an open source version with its Darwin base.
Mac OS X 10.0 Cheetah was the first official release (Darwin 1.3.1). macOS, is the latest flavor of this lineage.
As for macOS, it seems to be a UNIX open source version that Apple dubbed Darwin developed around 2001.
Sure, you might want to tag @Phil (that said, the manual already tells you that you’re going to get improved performance).
Word Clock In3 is primarily intended to be connected to the Upsampler’s Word Clock Output to improve performance with sources that do not have a Word Clock input.
If you need deeper technical explanation for why, I suggest you read the read James’ excellent explanation
Sorry, I’d forgotten the base being System V with load of BSD extensions. And Apple’s various versions of the OS also initially had lots of others extensions. Not sure what the current open source extensions have been developed over time.
What’s interesting about the dCS bit that James covers is just how it would be managed via the separate sync settings for the Upsampler and DAC. I’m thinking that using the MU1 source (Audio) setting for the Upsampler and then the W3 with the cabling for same may work, though it might complicate the data stream identification for 44k vs 48k variants. Hoping to hear from someone at dCS. Does James have a tag that I can apply to this post?
The question suggests that you are new to tagging. It doesn’t work like an email address. You do not need to know anything aside than to add @ before the moniker of the person within the text of your posting to the forum. You will find that after @, once you type the first letter of the moniker a list of members with the same first letter will appear. You just select and click on this and the tag will be entered. A copy of your post will be sent to the inbox of their personal mail client.
This thread has diverged a little into following the history of Mac’s software and your original question may no longer be obvious to a new reader. I would suggest that you send a new email restating your specific question to :
It could be possible that one of the team may already have seen your original post but remember that they have ben away for the Christmas/New Year period and may only fully return today.
When you have an AES/SPDIF source element (like the Mu1) that does not have a Word clocking input, that element has to be the master single source for clocking
Connecting that source to your Upsampler, you need to set sync mode to [Audio] which enables the Upsampler to slave its internal clock to the extracted clock from the AES/SPDIF stream (regardless of whether that source is streaming 44.1k or 48k based tracks).
The DAC has to likewise be slaved to that same clock, which you can get via the Word-Clock OUT from the Upsampler into Clock input 3 on the DAC
For all other source inputs, your Upsampler and DAC should remain in sync mode [Word Clock 1-2 Auto] for which your Vivaldi Clock is the master single Clock source (keep in mind Clock settings are input specific and remembered)
Hi Steve, Yes, the WordClock In3 input on your DAC is specifically for this type of scenario. The only other way to configure the clock regime with a source that lacks a word clock input is to recover the word clock from the data stream both at the Upsampler and then again at the DAC. The WordClock In3 input allows you to avoid this duplication. It should in theory make an audible difference although I have never tested this myself.
That said, I am curious. If you have a Vivaldi “short stack” (no Transport) why are you using 3 pairs of clock cables? You only need 2 pairs (plus 1 if you are using WordClock In3). Assume it was a typo?
To jump on this thread as well, Anup has it right. Your Upsampler needs to be set to Audio Sync when using the Grimm give its lack of ability to sync to an external clock signal. However, using a wordclock connection between the Upsampler and DAC means that the DAC doesn’t have to recover the clock information from the AES signal and can instead recover it from the wordclock signal which reduces jitter.
The downsides are that if you move to using a different source, you’ll need to manually change the sync mode setting on the DAC to reflect this (the Upsampler should change automatically as its input will be changing). Also, when streaming from the Grimm, the Vivaldi Clock is redundant as nothing is locking to it.
Thanks for all the feedback.
Firstly to Anup I agree that what you’re saying makes perfect sense. I’d also like to clarify that apart from the Upsampler’s own ability to act as a source via Mosaic for radio and UPnP / NAS Minimum server, the MU1 is my only other source. Roon feeds everything from 44K through 352.8K and the range of DSD material.
Secondly, I’m happy Andrew that you’ve joined dCS to lend your hand at support. It’s been quite some time since we chatted. And you’re correct: only using 2 pairs of clock cables needed for the Upsampler and DAC. So, it seems that the optional path out of the Upsampler to Word Clock In3 still carries the initial MU1 source but avoids any duplicate processing.
What I am unclear about is any benefit I would get or lose implementing this. In fact, am I receiving any clear benefit in the use of the dCS Clock in my current configuration, and what might that be?
Thirdly, James you’ve answered my query regarding the need for using my current dCS Master Clock at all. As an aside, I’ll disable my Cybershaft clock as well, since it was only acting as “overlord” to the dCS Clock and my etherREGEN network switch.
Given my single source situation I will proceed to power off the clock and use its clock cables in the recommended configuration and thereby offload the DAC’s redundant clock processing.
If all this works to my advantage I might have to consider upgrading to the Varèse sans Clock, if I could afford to do so.
?
MacOS is most definitely not based on Linux!! It’s based on NeXTStep which has a Mach kernel; very very different from Linux’s kernel (although they’re both Unix derivatives).
