There is a lot of talk that external clocks because of the distance to the processor don‘t work. This is the opposite of my experience. While I had used an external Antelope rubidium clock,on my Etherregen and Zodiac Platinum Dac, I have now added a Lhy Audio UIP clocked by the same Antelope Clock to reclock the USB stream emanating from the InnuOS Zenith MkIII. The resultant increase in soundstage depth, attack an decay and overall transparency isn‘t subtle. While there seems to be lots of focus on cables, accurate clocking throughout the chain seems still deemed unnecessary. I don‘t understand InnuOS‘ selling separate reclockers for USB and Ethernet without synchronising Ethernet input, DAC conversion and USB output.
I am merely sharing my views based on responses here and other threads. It was not my intention to offend or isolate anyone. @antigrunge2and my experience with an external clock are nothing but exemplary. I must admit, implementation and choice of components (including clock cables) are the key when pursuing such ultra high resolution endeavors. For most folks, internal DAC clock would be sufficient and provide plenty of thrills. Also, whether one can hear the differences with a master clock synchronizing multiple components such as DAC, Streamer and Switches would largely depends on the downstream components.
You don’t need to take my word for it, just study the systems that are using high quality external master clock. Peace!
No problems, thanks for clarifying. I love it that people are so passionate about this hobby over here. In my engineering mind an external clock in the home environment could cause more trouble ie introduce jitter, impedance mismatch, etc BUT lots of things don't make engineering sense in our hobby but do work... like cables. So I hear you. I have tried a very good clock source from work in my system at home and the result was inconclusive, to be honest I don't think I could hear a difference. As you say it could depend on implementation and system specifics. I am glad both you and @antigrunge2 have improved your systems with an external clock source and you are enjoying them more.
As you can see, you have two kinds of posters here. One that have tried and implemented an external clock to a greater benefit. And then those, who have been peddling their ideas based on ‘documentation’ i.e. no direct experience 🙄
There are also posters in this thread that have added a clock and heard no noticeable difference and were willing to admit that. And those that achieved significant improvements by upgrading their DAC, rather than trying to wring some small improvement out of their existing DAC by adding a clock.
Which isn't to say that adding a clock might not be an improvement with some DACs. If you hear a difference and the cost was worthwhile to you, then it was a good investment.
It is vitally important in such discussions that we avoid conflating/confusing the ethernet domain (up to the input side of a streamer) with the bitstream domain (output side of streamer onwards).
@erik_squires is spot on here. The ethernet domain is asynchronous and based on packets/frames being distributed, with error-checking and resend built in to the 7-layer OSI protocols. It stops at the streamer where these packets/frames are converted to a continuous bitstream. At this point, streamer output side onwards, clock accuracy is important to sound quality but there is no mechanism for clock accuracy in the ethernet domain to have any effect on sound quality.
An ethernet clock may be quieter of course, and this could conceivably impact SQ, but I’ve never heard any manufacturer argue that theirs is.
Innuos are careful in their PhoenixNet blurb NOT to assert that the clock they use in it, which is the same as in the Statement I believe, has the same effect on sound quality. They talk instead about the proximity of the clock to processor avoiding the risk of data losses which might conceivably occur with an external clock (though personally I struggle to see this).
I can only reiterate what I hear: Etherregen with and without external clock are miles apart. So something happens ahead of the streamer that is affected by the clock. Interestingly John Swenson acknowledge the beneficial effect in his white paper, too.
Let‘s just say that my ears and reputable designers like Innuos, Esoteric et al disagree with you
Dont simply trust “designers”. Companies want your money and will happily sell whatever for a profit. Always verify their claims. I have seen big, imposing chassis from a very reputable company which should stay unnamed, that was literally empty inside with puny power supply and 2x2” PCB board. I costed $$$$ and got rave reviews.
@antigrunge2I assume you mean Phoenix NET network switch. I can theoretically imagine that streamer has underpowered CPU and low performance network stack and hardware so an extra switch before it helps.
The network switch may be set up to filter out other traffic (like your kid playing Warcraft) so only audio related traffic reaches the streamer. It is possible that streamer CPU is low performance in order to avoid spinning fans and cooling issues.
You count obtain your own network switch for like $100, but setting it up properly may be a challenge unless you are proficient in IT.
Network switches used to improve sound quality (rather than just giving extra ports as originally intended) do so by massively reducing the amount of RFI reaching the streamer. I guess it will also filter out other traffic in the process, but it’s the RFI from other connected devices rather than some sort of digital crosstalk.
An unmanaged switch will do just as good a job of filtering RFI as a managed one, as the management bit is nothing to do with RFI.
@antigrunge2You said "I don‘t understand InnuOS‘ selling separate reclockers for USB and Ethernet without synchronising Ethernet input, DAC conversion and USB output."
The PhoenixNet operates purely in the ethernet domain to kill RFI noise, it is not there to improve signal timing accuracy so decribing it as a reclocker isn't really accurate (this implies the improvement in sound quality which PhoenixNet users report is down to more accurate clocking and it's not).
You can't synchronise asynchronous (ethernet) and synchronous (DAC); it doesn't make sense.
I stand by what I hear and am not impressed: why would InnuOS include an expensive Ocxo clock if it has no benefit? And reclocking the Etherregen is very audible. so what is your equipment and reference base for making all your statements?
Well, some reviews claim "The Innuos PhoenixNET will also improve your music playback from the files on the music server itself. Even though that music isn’t being streamed through the PhoenixNET. You heard that right."
Well.... something not even connected somehow improves the sound. OK.
Some digging around revealed that, for example, Ethernet does not do error correction. it does discard corrupt frames though. and TCP will retransmit lost packets. So the switch may be simply buffering frames and then transmitting in sequence on cable with fewer dropped packets. How does it affect the sound? Depends on quality of the streamer.
@nigeltheflash - Do you mean RFI on the twisted pair or in the space around the unit? Simple shielding or or galvanic isolation would drastically reduce RFI. Not sure about necessity of switch for that purpose since it runs its own CPU and hence makes its own RFI.
@antigrunge2Re Innuos, you’d have to ask them but I suggest you first carefully read what they say on their website about the contribution of the clock to the performance of the PhoenixNET. I suspect it’s economies of scale: they needed a clock of some sort (all switches do) and they already have one which they know is both accurate and quiet. Why source a cheaper clock which may also be noisier in RFI terms?
You asked about my equipment. I use Cat 6A shielded cable into a Reiki Audio SuperSwitch into Innuos Pulse Mini with a Zen Mini MkIII power supply which has been moderately pimped to improve its performance. I have used a short (0.5m) Cat 6 unshielded from Pulse to dCS Puccini DAC (with external U-Clock) but am enjoying other short cables here so will swap the Cat 6 out.
@mikhailark On your point about local file playback, Roy Gregory was surprised to find a similar improvement with his Wadax server/streamer (see page 5 herehttps://gy8.eu/review/magnificently-minimalist/5/. I agree with his hypothesis that if there is less RFI going into a server/streamer via the ethernet connection then that will logically affect even local file playback.
Re RFI, I mean both. Yes a switch generates its own RFI but steps can be taken to minimise that generation and the massive reduction a good switch makes to reducing incoming and therefore "net" RFI is clearly audible.
Disclosure: as per my profile, I design and build switches for audio purposes so I have spent loads of time working out what can/does and can’t/doesn’t make a difference to sound quality.
My key point in contributing to this thread is not to argue the merits of various RFI-mitigating approaches (that has been and can be discussed elsewhere). Here I simply wanted to point out the clear difference between clocking in the asynchronous ethernet domain and clocking in the synchronous bitstream domain.
Thanks @antigrunge2. Unfortunately changing to this mode still leaves the physical network connection in place if you stream AND play local files so the challenges and the possible solutions remain pertinent.
About local files, couple of distinctions in my setup as to why local files sounds superior to those being streamed from Qobuz/Tidal:
1) No network noise and latency due to files being played from internal SSD storage of N30SA.
2) 95% of stored files are digitized from analog tapes and direct DSD.
IME, Tidal/Qobuz files are a mixed bag due to unknown provenance of files. There are some really stellar sounding files and then there are some that are simply unlistenable (to me). Not to mention, variables in our home network and equipments rendering the final sound. If one thing I learned with digital streaming is this, there is no streaming components at any price point out there that sounds optimal right out of the box without tweaking the home network.
Fully agreed. InnuOS does though offer a feature for playing local files while isolating the ethernet connection, the so called offline mode under Sense. It would be interesting to know whether disconnecting the ethernet cable from your Auralic equally improves the sound when playing local files.
Isolating Ethernet is not an option for me. My DAC is optimized to accept digital stream over Ethernet. I am streaming local and cloud based files from Aurender N30SA to Merging Technologies DAC.
I believe severing Ethernet connection from your Innuos player should impact App connectivity to the player, right?
@antigrunge2”It shows that the ethernet is a major source of DAC disturbances and some believe that clocking matters in that context.”
I’m not sure what you mean by “DAC disturbances” other than RFI noise affecting the analog(ue) part of the DAC. The streamer will have received ethernet packets/frames and unpacked these into a bitstream which it feeds to the DAC; the DAC itself doesn’t see anything ethernet. Except RFI noise which may have accompanied the digital signal created by the streamer of course.
If some people not only believe ethernet clocking can make a difference but experience that it does, we then need to move onto the mechanisms which might make this possible. Clock accuracy is not one of these, as explained earlier regarding its asynchronous nature. Something else may be at play and many of us would, I’m sure, be interested to understand what these mechanisms might be.
may I suggest you read John Swenson‘s white paper on the Etherregen.,It is available on thhe uptoneaudio.com website. There is also an addendum on using external 10m clocks
@antigrunge2You may indeed suggest that but I have read it before. While I congratulate John on an excellent piece of marketing, often referenced by people as if it has a peer-validated and objective status it does not, it contains many misunderstandings and factual inaccuracies.
while you are entitled to your views the fact remains that reclocking the Etherregen has an easily demonstrable effect. John Swenson in opposition to you acknowledges that. And Reiki Audio‘s point that manufacturers include expensive Ocxo clocks in switches ‘because they have easy access to them’ defeats normal commercial logic.
It may well do. I merely assert that this cannot be anything to do with the greater accuracy of the external clock.
Reread what Innuos say about the clock in the PhoenixNet. They are careful not to attribute anything to their clock’s accuracy in this context. They know what they are doing.
If you work in a commercial capacity yourself then you will appreciate that economies of scale may indeed make it straightforward for a company to use a clock they know to be quiet rather than to invest precious R&D time and money seeking to source a cheaper clock that is similarly quiet.
You clearly believe ethernet clock accuracy has an impact on sound quality. If you could explain how, in your own words, the timing of an asynchronous error-correcting buffered data stream which is transformed into a completely different format by a streamer can have any effect at all on sound quality then we may have a basis for further dialogue. If not then I’m out, content that I have made my point clearly.
From the InnuOS website on Phoenix Net: ‘The PhoenixNET is the realization of Innuos' philosophy of simplicity and signal purity applied to the network switch. Having started with improvements to the Ethernet ports' clock on our flagship Statement, Innuos has now brought the concept to a network switch design that focuses exclusively on audio use for musical details that stand out, a blacker background, better instrument separation and realism.’
Sounds very much like InnuOS thinks the clock on the Ethernet port matters, doesn’t it?
Scroll down. Precision is about proximity not about reclocking. This proximity "avoids data losses" which are hardly likely to happen anyway (when did you last experience data losses on your internet connection?).
"02.
Increase Clocking Precision and Stability
Using the same 3ppb 25MHz OCXO oscillator as used in the Statement, individually powered by its own linear power supply and connected directly to the network switch chip, avoiding precision losses from using external master clocks."
Each of us is free to believe what we want but facts are facts. Innuos play it safe here. dCS are on record as saying ethernet clock accuracy can't make a difference to sound quality. However the broader industry is rife with misunderstandings of this domain, almost always arising from inappropriate extrapolation from the post-streamer domain (where jitter is a real thing affecting sound quality and clock accuracy is king) to the pre-streamer domain where it is not.
Google "OSI Model" and focus in on the Physical Layer which requires clocking. The reflect on how any timing information might be relevant to sound quality, given that the streamer will apply its own timing when it converts the packets to a bitstream.
I am sorry but you are being argumentative: on your logic the clock in the device is superfluous yet InnuOS expressly extoll its importance and the attached review of the device amply speaks to its sonic benefits. The same applies to Uptone‘s Etherregen so I am frankly not interested in further reiterations of your postulate. Over and out.
As you know, it takes two to argue. I'm merely reasserting my position every time you reassert yours.
On my logic, the accuracy of the clock in the ethernet domain is irrelevant to sound quality. I absolutely do not assert that the clock is superfluous, you're putting words in my mouth. A switch needs a clock to function.
You have yet to offer any explanation of why/how ethernet clock accuracy could possibly affect sound quality. Noise generated by the clock could differentiate one clock from another.
Acording to your logic, if accuracy of the clock in the Ethernet domain is irrelevant then why some of these switch manufacturers (I can name a few) advertising the importance of clock in a switch. Excerpts from Reiki Audio blog you linked in your post.
“Reiki Audio SuperSwitches employ an enterprise standard 25MHz clock which delivers the highest possible audio performance.”
The clock signal in a digital circuit serves as a timing reference. The clockhelps coordinate when data should be read or written, ensuring proper sequencing and functionality of the circuit. If a switch needs a clock to function then by all means a cheap or subpar clock can easily degrade the audio. No one here is arguing over IP…I believe the core of the argument here is why OP heard audible improvement by connecting a highly accurate external clock which is obviously superior than the one included inside the EtherREGEN.
IME, anytime you can improve the accuracy of clock, you’re likely to hear audible improvements. The magnitude of these improvements are clearly system dependent and one’s listening skills. The proof is in listening and not waging an argument “oh that’s simply not possible given the standards sets by TCP/IP”.
I fully accept that an external clock might improve sound quality. I don’t accept that the reason for this has anything to do with the accuracy of the clock. That’s all.
Think about or investigate what a streamer does. Its job is to repackage lumps of data into (effectively) a continuous stream of data. It completely reformats it and the accuracy of the clock in the streamer is important to sound qualiity (I used to have a Mutec MC-3 reclocker after my streamer); ditto the importance of clock accuracy in the DAC (I continue to use an external clock here myself).
I am happy to stand by my assertion that there is no possible mechanism through which ethernet clock accuracy affects sound quality.
‘I fully accept that an external clock might improve sound quality. I don’t accept that the reason for this has anything to do with the accuracy of the clock. That’s all.’
Congratulations on inventing a negative inverse tautology’
it all depends what is understood by the term 'clock accuracy'.
For example rubidium clocks have very poor short term stability, they jitter by design. This makes them totally unsuitable for a short term time base reference. Their big usage is due to their long term stability where the time has to be correct after a long time without synchronization (eg military applications). The long term frequency stability, the clock 'accuracy' is defined in ppm (part per million). The highest clock accuracy is not required for hifi applications.
An OCXO (or TCXO) has a better short term stability (phase noise) but is doesn't have the accuracy of the rubidium. .
As in hifi the real long term stability isn't important, the better clock source is a very high quality OCXO or a TCXO.
My point is that the absolute accuracy of the clock is not as important as other aspects of it (phase noise, voltage stability, jitter, etc).
@antigrunge2 I said "I fully accept that an external clock might improve sound quality. I don’t accept that the reason for this has anything to do with the accuracy of the clock. That’s all"
You said "Congratulations on inventing a negative inverse tautology". I haven't. Please re-read. I choose my words very carefully.
You keep asserting that any reported sound quality improvements from an external clock must be due to its accuracy; I keeo asserting that it can't be, so we need to look elsewhere for the cause. I do NOT assert that an external clock cannot improve sound quality; I merely and persistently question your attribution of the effect to a cause.
@greg_fGreat post. Indeed, short vs long term stability is a key concern as dCS are particularly keen to point out.
This is in the bitstream domain though. Neither applies to the asynchronous ethernet domain. The streamer is where clocking, jitter, etc become real concerns impacting sound quality, not before.
You must have a verified phone number and physical address in order to post in the Audiogon Forums. Please return to Audiogon.com and complete this step. If you have any questions please contact Support.
