Sorry if it wasn’t clear Steve, let me try to clarify:
When using the Grimm as a source connected over AES3 you gain no benefit whatsoever from your Vivaldi Master Clock. A source connected over a synchronous connection MUST be synced to the master, therefore if the source lacks a clock input it must be the master.
Connecting the Upsampler’s WordClock Out to the DAC’s WordClock In3 allows the clock extracted from the AES3 stream by the Upsampler to be passed to the DAC without it having to be extracted from the AES3 stream again. In theory this should lower jitter, but only you can judge any sonic benefit in your system.
Given the use cases you describe the Vivaldi Master Clock is only benefitting you when you are listening to Internet Radio and material sourced from your NAS (as these enter through an asynchronous connection - the network).
Thanks. I’m a bit foggy on your last point. When I listen to internet radio, Qobuz, or my NAS-based local library, it’s coming into my MU1 via my Roon Server on the MacMini that’s Ethernet connected to my switch. The MU1’s input, in this instance, is also via an Ethernet connection coming from the same switch.
The Upsampler is, of course, Ethernet connected to the same switch.
The only thing that differs in the data flow to the Upsampler is whether the input is AES/EBU from the MU1 or via the network connection, which allows Mosaic to play Internet radio, Qobuz, or UPnP(Minimserver on the NAS for my library).
Is this what you’re referring to? That a pure network-based path through the Upsampler to the DAC takes advantage of the Clock?
Exactly. Anything that enters the Upsampler through its ethernet port is asynchronous and therefore subject to the clocking regime that you have selected for that input, which for best sound quality in your case would be to select the Vivaldi Master Clock as the master with sync mode Auto.
Can I just clarify that this would be sync mode W (Auto Wordclock) not sync mode A (Audio) … for the network input only sync modes of M (Master) and W (Auto Wordclock) are available.
Thanks to all who’ve chimed in. Until this point the only way to allow me to listen to my system with the MU1 source, as wired, was to have both the Upsampler and DAC use Audio as their respective sync settings.
So, the first thing I did after all recommendations was to compare what I was hearing to date by simply turning off the dCS Clock. Result no noticeable differences, as you’d expect.
Then I removed all the clock cables in the system and used one to connect from the Upsampler’s Word Clock Out and the other end wired into the DAC’s Word Clock In 3.
I left the settings on both Upsampler and DAC sync settings as is (Audio) to check whether either would complain (e.g. Bad Clock indicator). Of course, nether indicated any clocking issues. Nor did I experience any sonic differences again.
However, once I set the DAC Sync Mode to Wordclock 3 I heard a better SQ. This appears to confirm everyone’s expectations about keeping the DAC from “reconstituting” as Anup says. And as James spelled out for me, using Word Clock In 3 from the Upsampler avoids any recovery action for AES signal clock information, and simply get it from the Upsampler’s word clock signal.
So, the “jitter” that everyone expected, and which seems to have “disappeared” after all of this, has resulted in better SQ. More “relaxed” sonic presentation that seems clearer with a bit blacker background. I think I’m hearing a more transparent and detailed presentation, Even the dynamics seem greater. Likely as I listen more other aspects will become more apparent.
Once again, thanks to all. Until I gave up on prior iterations of network-based streamers (like the Roon Nucleus, which apparently allowed the dCS Clock to do its thing) I wasn’t aware of the MU1’s very different synchronous nature. Yet considering how much better the MU1 is as a source I would find it hard to go back to any network-based player. Live and learn…
Great to hear Steve! I am glad you are happy and also glad that you are hearing the benefits of an improved clocking regime (in this case avoiding an unnecessary AES3 clock extraction) which are completely consistent with other steps up the clocking “ladder”. In fact your observations rhyme well with one of my earlier posts.