I have my eye on a Innuos Stream 3, or even a Innuos Zen/Zenith Server. (Not yet demoed)
I would use my Bartók purely as a DAC, and let the Innuos do the Streaming/Server duties. I will install a WD Red NVMe SN700 SSD (Recommended by Innuos) for all my ripped CD and HiRes 24/192 FLAC files.
Not all, but most appear to prefer LAN over a USB connection to their dCS DAC. However, would adding a Reclocker, either by means of a pre installed PhoenixUSB Board, or the stand alone PhoenixUSB Reclocker, make the USB connection superior, or as good as LAN?
I recently saw two YouTube reviews, where computerised measurements were taken with, and without the Reclocker. The result…No change in the sound. Is it the case that dCS DACs Reclock all incoming data anyway?
My dealer of course, states the Reclocker will blow a LAN connection out of the water.
I am interested to know what Innuos product owners feel about USB Reclockers, or those that use other brands of USB Reclocker.
I use a Pulsar into my Rossini Apex and it has the PhoenixUSB Lite output. I would need to be more of a committed optimiser to do the exhaustive testing required to give a defniitive answer but I’m too busy loving the music the combo produces!
Innuos stress that they don’t reclock the data signal itself. It is best not to think of the PhoenixUSB, full-fat or Lite, as a reclocker, just think of it as a filter. It’s probably acting as a noise filter in the same way as the PhoenixNET cleans up an ethernet signal. The sparse feedback I’ve seen suggests the PhoenixUSB Lite gives at least 90% of the benefit of the dedicated unit at much lower cost and taking up much less real estate.
It would be more correct to say the DAC clocks the incoming data stream than that it re-clocks it. Unlike AES-3 or S/PDIF, USB Audio is asynchronous and is always replayed from a buffer in the DAC, there is no timing information in the audio to re-clock. The PhoenixUSB reclocks USB at the underlying protocol level.
USB “reclockers” are a bit of a misnomer; asynchronous stream don’t need re-clocking, instead, such devices mitigate USB’s inherent disadvantages which Andrew explained to you (back when you first posed the USB vs. Ethernet question), through galvanic isolation to minimize ground noise, and improved signal integrity (electrical signal-to-noise-ratio) to minimize errors.
Whether they do that effectively enough to bring it on par with native Ethernet streaming on dCS is kind of up to you do decide
We’re really getting down in the weeds here. If you’re not familiar with it I suggest you read up on the OSI model (if you Google around you’ll find much more readable explanations, but the Wikipedia one is at least authoritative), in order to understand how communications protocols are layered to provide abstraction at multiple different levels.
USB is a highly flexible protocol that can be used to connect just about anything in the PC world to just about anything else. Hard disks, monitors, mice, printers, you name it. So at its lower layers it is a general purpose protocol, it is up at the Presentation and Application layers that it becomes application specific, where streaming audio would be one such application.
What I mean is that down at the Physical layer USB is synchronous, similar to ethernet. It fundamentally needs to signal 1s and 0s with a high and low voltage level, and without agreeing a standard time interval (the transmission bandwidth) it would be impossible for the receiver to distinguish a 1 from a stream of consecutive 1s.
However when sending audio, that synchronous “bit pipe” is used to send packets of audio data which contain no timing information. They are reassembled at the receiver and replayed from a buffer under the control of a local clock, hence asynchronous.
As Anup says, the PhoenixUSB does a lot more than re-clock the bit pipe, it actually completely regenerates it, clocking it with a local OCXO in the process. Please don’t ask me to explain how that benefits the audio delivery process, I haven’t seen any explanations of that. Apart from anything else it would seem to imply some sort of failure in that abstraction system. If anybody knows of one please link it here.
I did attempt to read the Wiki OSI Model, but by the third paragraph it got the better of me. Having dealt with many Criminal Investigations, spanning a 30 year career, I would consider myself to be of average intelligence, but the OSI Model went straight over my head! I say this with a big smile
Thank you Andrew for explaining that, fully understood
I wasn’t aware the Pulsar could accommodate various modules, including the PhoenixUSB Lite output. Without going off my own topic, why did Innuos bin the Pulsar? I’m thinking for the Stream Series
I have one spare shelf on my Quadraspire X-Reference rack, so the PhoenixUSB Lite module looks a good option for the Stream or Zen. Thanks for the heads up
They crashed together the Zen and Pulse ranges into the new Stream and offered options of storage and non-storage within that consolidated product range. Personally, I think the previous separate product ranges were much more readily understandable, but hey what do I know! There is zero evidence so far that there is any better streamer within the Stream range than the Pulsar, so think of it more as a rationalisation of their product ranges, a re-branding of sorts, rather than any sort of step up in capability.
As someone who implemented the first five layers of the real OSI protocol, I find this hilariously simplified! The real OSI protocol was so complex, almost nobody used it. That’s why TCP/IP became ubiquitous. It is so much simpler. It doesn’t really follow the OSI model exactly, and only comprises the first 4 layers.
My dealer also recommended the USB connection over LAN and, in fact they use USB in-store to connect their Nazare to their Varese. I verified their claim with a weekend loan, ordered the Stream. Now that I own it (after a five month wait!) I can easily switch from USB to LAN connection and the USB has greater presence and immediacy. And my LAN is no slouch; fiber from the gateway router directly to the Innuos, with an AfterDark media converter at the router, and waiting anxiously for the EtherRegen2 at the Innuos end.
Having dealt with many Criminal Investigations, spanning a 30 year career, I would consider myself to be of average intelligence, but the OSI Model went straight over my head! I say this with a big smile