The common PCB that you see in all of the Vivaldi stack components is dCS’ Control Board (the “DCS400540”, left in the image below).
If I’m not mistaken, it’s an updated design based on the control board in the Scarlatti, and has a lineage that dates back to the earliest days of dCS platforms; I/O processing, RS232, Clock generation and PLLs, and connections into the DAC processing board etc. It wasn’t originally designed just for the Clock.
All of boxes in the Vivaldi stack have this same common Control Board in them, with appropriate power, I/O, and software tweaks for each.
There was another thread about the upsampler. Someone suggested combining streaming in the dac might produce suboptimal results. Spent some time thinking about this, admittedly with the expertise of a naive five year old, and question if the benefits of having the external streamer are negated by the use of aes cables into the dac. My working theory is that it would make little difference and streamer was included in upsampler because it wasn’t considered a “must have” interface during design. Don’t have sufficient expertise to examine the question of why the streamer was tied to upsampler while the dac has a USB port.
The existence of the NWB supports my theory that upsampling & streaming aren’t intimately connected processes. If this is true then the upcoming Ligeti dac will definitely include streaming.
This is partly because one has the opportunity to buy all 4 boxes of Vivaldi simultaneously or one or more at a time . So I guess that dCS decided that someone who bought only the DAC may want to have a USB input. That is a different proposition to placing a complete network streaming board there. In fact my initial Vivaldi configuration used that USB input on the DAC ( I had no Upsampler) for PC based streaming. It was , however, significantly inferior in SQ compared to the dCS streaming solution - I wish I had known sooner.
Historically no dCS DAC had a USB input until the current third generation. USB was not a consideration for the first generation. It didn’t exist at the time. The second generation initially had the USB input on the upsampler ( you can see the lineage there). However the USB input was moved to the clock for some reason ( not to the DAC). That move resulted on the ability to process a wider range of input resolutions.
Indeed upsampling and streaming are not necessarily linked. NWB was, of course, introduced to provide appropriate connectivity and functionality to owners of legacy dCS equipment who otherwise did not have the ability to play formats developed later ( hence NWB downsampled not upsampled) including streaming options.
The forthcoming Britten stack may not follow the configuration of its predecessors for all we know. One speculation I have read here is that it could follow a sort of dirty box /clean box concept with a control box containing streaming /upsampling/user control functions including volume plus two mono only DACs in separate cases. It was , however, just guesswork on the part of the poster. We await what it really will be in due course. However I am pretty sure that I won’t be able to afford it anyway and will have to admire it from a distance .
The picture of the internals of the clock shows it only contains the control board. I sort of expected to see something unique to the design. However, after thinking it through, in a “cost no object“ design, whatever they did to the external clock they would also do for the internal clock. Unfortunately I’ve tried to understand how/why the external clock improves sq but it’s way too technical considering my background. The external clock would benefit from an isolated power supply and a lower noise environment. That is enough to explain why it would likely be a more reliable signal. Whatever complicated maths involved with integrating the external and internal clocks becomes irrelevant. The problem becomes more interesting when the external clock signal has to flow through 1 meter of wire with electrical properties unknown to the designers. Is it really simple in that regardless of the properties of the bnc cable, the signal will be consistent and that’s what matters?
The reason I’m interested is that I was earlier considering a MSB reference dac. It’s fascinating that two companies can have completely different design philosophies yet produce competing products that are extraordinary. MSB design has an edge in the “yeah I get it” area. Putting the best possible clock 1/2 inch from the dac is pretty intuitive. Again I can’t prove this design is optimal. It’s also possible dCS engineering is much more sophisticated and creative.
The point of a system clock as used in the Vivaldi stack is not just to be more accurate than the clocks in the individual components but also to synchronise those three components. Otherwise each will be running its individual version of a 44.1 or 48 kHz one second long cycle. So, as an exaggerated example, if Transport starts its 44.1 kHz cycle now, DAC might not start for another 10th of a second. So by the time transport has completed its one second cycle of 44.1K “pulses”, DAC is still only part way through its. This means that each individual cycle becomes further and further out of synchronisation with the other as time progresses leading , for example, to audible glitches . The system clock provides a single clock signal distributed to the other components. This alone would be reason for having it even if the clock accuracy per se was no better than the individual component clocks. However in fact it is which is the second reason for an external clock which is pertinent to Rossini ( used without Transport) and Bartok .
Which is, as I understand it, what is still happening in the stack ( I think I have this right). The individual clocks are not switched out but are slaves of the master system clock. So they are positioned close to whatever processor they serve but are all working identically to the same and more accurate master reference.
.