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.
Everything upstream of a streamer is what we call asynchronous. The timing is always rather loose as an Internet based connection does not have guaranteed latency or inter-packet arrival time. Attempting to add picosecond clocking to those events which are varying by hundreds of milliseconds is madness. For reference:
0.1 seconds is 100 milliseconds is 100,000,000 picoseconds and 100,000,000,000 femtoseconds.
This is why TV’s and streaming devices have relatively large buffers. Everything goes into a bucket which it attempts to keep full from one side, and then carefully doled out by a metronome on the other. That’s where the clock matters.
Everything else, IMHO is to keep the noise out of the AC lines and interconnects.
As an example, I've watched my Internet fail and failover to a backup Internet provider. The process takes around 70 seconds during which I had no Internet. My music never stopped playing.
@erik_squires”This is why TV’s and streaming devices have relatively large buffers. Everything goes into a bucket which it attempts to keep full from one side, and then carefully doled out by a metronome on the other. That’s where the clock matters.”
I think that minimising jitter throughout the digital chain rather than just at the A/D conversion stage has primary importance. Buffering is not a recipe for avoiding jitter. And it‘s the quality of the clock more than the length of the cables that matters
Um, yeah, OK. I’m going to sit here and wait for you to explain to me how on earth you would even reclock a TCP/IP stream without actually buffering it.
Yes, it is. With asynchronous USB data is delivered in packets (frames) to buffer at some time intervals, for instance 1ms - for instance 44 samples, DAC delivers each sample to D/A converter in exact intervals (cannot be improved) signaling back buffer over/under flow. Problem of data coming at different or uneven intervals is eliminated by the buffer and back signaling. Synchronizing time of the frame delivery with D/A clock won’t help because D/A converter already operates at exactly even intervals.
In case of SPdif buffering in DAC won’t help because without back signaling data night be coming too fast or too slow. It can be fixed by reclocking or most often to adjust D/A conversion rate to average rate of incoming data.
What might help with asynchronous USB is isolation that prevents injection of electrical noise from computer to DAC. Reclocking has nothing to do with improvement but people buy it likely because it sounds promising.
What about the clock accuracy releasing the buffer, then?
I specifically addressed this in my first message. You literally can’t avoid jitter without buffering, but in the case of a network stream from outside the home having more "clocking" at upstream devices, without buffers doesn’t help you because the original stream has huge amounts of packet to packet variation (huge relative to an audio or video playback). In fact you can end up in a situation where your original DAC’s jitter is worse because there’s an upstream "reclocker" that has so much jitter it’s forcing the downstream DAC to misbehave.
The best possible place to put a fancy clock is less than an inch away from the DAC. External clocks are used to produce music in the cases of multiple DAC’s or streams happening at once, as in the case multi track recordings and mix-downs. Those clocks do NOT however dejitter anything.
In my setup both the Etherregen on Ethernet and the UIP on USB can run on their own clocks or supported by the 10m clock. The difference in sound quality isn‘t subtle and that is what my post was about. It seems you are arguing from first principles rather than own experience
What about the clock accuracy releasing the buffer, then?
It is internal DAC’s clock that is unaffected by any external activity (asynchronous). DAC uses this clock to take sample of the data from the buffer and convert it to voltage at exact intervals.
It does not matter if this internal clock is inaccurate. We cannot detect if music plays tiny fraction of percent slower or faster, but we can hear when this clock is jittery because uneven D/A conversions intervals add additional frequencies to audio signal. We likely cannot hear jitter artifacts when jitter is below about 50ps (peak to peak) so names like “femtosecond clock” are nonsense.
Releasing a dirty stream to the D/A increases its processing load leading to distortion. This applies to all dacs but is particularly noxious when using upsampling. That‘s why reclocking the data before conversion has benefits. And by the way, excessive buffering leads to latency while underutilized buffers need empty packets fill-in, again increasing the processing requirement on the D/A converter. Be that as it may and as stated previously: in my setup the benefits of external master clocks is easily demonstrable
Releasing a dirty stream to the D/A increases its processing
No it doesn’t, latency has nothing to do with it and buffers are never “underutilized” because of back signaling.
Perhaps example will help:
Worker (DAC) has to place items on conveyer belt (D/A Converter) of some machine in exactly one second spacing, but another worker (computer) hands them too slow or too fast creating uneven space between them. Remedy for that would be shelf with many items on it (buffer). One worker adds bunch of them (frame) to the shelf every so often and the other places items on conveyer belt in even intervals, yelling back “get more (or less) next time” to keep decent amount of them on the shelf (back signaling).
@antigrunge2What processor? The only one that can affect timing of D/A converter is in the DAC. It loads samples from the buffer into D/A converter at even time intervals. It also signals back when buffer is too empty or too full.
Sending asynchronous data in packets is reducing stress on receiving end allowing receiver to get data in the required or convenient time.
AFAIK there is no error correction with asynchronous USB. Frames contain checksum (CRC field), but I’m not sure if computer resends the frame. In plain USB transfers device on receiving end sends back “negative acknowledge” (NAK) and frame is resent.
Asynchronous USB is reclocker. Placing another reclocker in front of reclocker won’t do anything. Perhaps these devices were initially intended for synchronous or adaptive audio USB. Asynchronous USB came later. Another benefit is electrical isolation from noisy computer. Reducing electrical noise injected into audio device is always good. If your reclocker is improving sound by doing this then it is worth the money.
Isn't the best place for a clock to be inside a dac, why don't dacs have better clockers?
I have to believe many do. And if they don't buy a better dac. Adding this type of peripheral is just insane. Much better to integrate with all the wiring and crap that goes on when you have to connect a separate clocker.
Let‘s just say that my ears and reputable designers like Innuos, Esoteric et al disagree with you
Disagree with what? I don’t question you can hear the difference, but I attribute it to electrical isolation that device brings and not the reclocking process itself.
@emergingsoul+1. Any external clock will have to be connected by a cable (50 or 75Ohms) of course. This will cause smearing of the clock signal, it is not the frequency of the clock but the rise and fall times of the edges that are difficult to control without introducing several issues like overshoot/undershoot of the transitions (could cause more noise / jitter) and uncertainty (frequency / phase shift / linearity). In my book the clock source needs to be as close as possible to the DAC IC with proper PCB impedance control. An external clock source is required in a studio recording environment in order to sync several devices together.
Thank you for the response but it's not helpful versus what I was trying to say. Doesn't really clarify the essence of what I was trying to say.
Seems to me a better Clock needs to be designed for inclusion within a dac. Adding a separate Clock and dealing with all the interconnects doesn't really help for something like this. Better to deal with all the wiring within the component for a better clock. Do you disagree?
And by the way: your sophisticated views would obviate the setups of any major recording studio where clocking of multiple devices with very long cables is standard practice
Perhaps I wasn't clear, I much much prefer a clock within the DAC than an external clock source. The better DACs have an extensive clock design. I believe something that separates a good DAC for a great one (both using the same DAC chip) is the (internal) clock circuitry, the power supply and the output stage of it.
DCS, Weiss, Meitner to name a few. But you are missing the point, the external clock is much further away from the DAC IC (assuming an integrated type) than the one inside the DAC unit. You have the extra cable to feed the external clock to the DAC unit, the length of the cable, the impedance, exact termination need to be taken into consideration. In the case of a square wave clock output, as I said before, the edges are extremely fast and need to be contolled.
A recording studio is using an external clock as much for synchronization as for anything else, as they often have a situation when devices are daisy-chained together and must work together correctly at every clock beat. The multiple pieces of equipment can't "hear" each other the way an orchestra does, so the master clock is there to make sure all the different pieces are in synch.
It's the daisy chaining effect that CAUSES jitter unless mitigated by the master clock.
On the other hand, with Internet streaming, there's no such synchronization.
PS- Error correction is taken care of by the TCP portion of TCP/IP and handles requests for retransmission when packets are corrupted. Another reason for big buffers, having enough time to ask for a retransmission when an error occurs.
It is helpful to clarify whether the application is using s/pdif or asynchronous USB.
For s/pdif, I think DCS uses what they call "reverse clocking" to minimize jitter in this case an external clock makes sense. The clock comes from the DAC domain and is used to clock out the transport data. In this case it is mostly mimic what you have to the asynchronous USB.
For asynchronous USB the data clocking comes from the DAC domain so an external clock may not help much. For this, you probably want to have the clock physically as close to the DAC as possible which is the implementation of most USB DAC anyway.
But there is a but. In asynchronous USB, if the incoming data has a lot of noise, it may inject that noise into the DAC circuit, so you could argue buffering the data with a reclocker will clean up the noise and therefore improving the sound quality.
Andy has a very good point. In the case of SPDIF or AES the clock is embedded in the data stream is more prone to jitter therefore the clock of the source/streamer is critical and IMO could benefit from a good reclocker with a good clock cct and its associated PSU. There are some transports that have a clock input so that the clock from the DAC can be used to clock the data in the transport. As Andy says async USB is supposed to eliminate this issue since the data is clocked by the DAC. Again I agree that a good reclocker/DDC could clean up the USB jitter (noise) but it all depends on the quality of the equipment. The reclocker’s clock needs to be of superior quality to that of the DAC’s one. I believe I2S is the best interface available, it was first designed as an interchip protocol but I see lately is being used to connect sources to DACs. That is fine as long as the interconnects are kept as short as possible.
I had a highly modified Oppo used only as a digital transport (all audio/dac board removed e.t.c). One of the mods was an upgraded clock - but not just that - a unique dedicated linear power supply just for the clock alone. This hugely lifted the performance of the transport. I was running it spdif out to an external DAC.
Interestingly the clock was a SAW (Surface Acoustic Wave) clock, not an TCXO or OCXO. The people behind this mod were adamant that SAW clocks were superior in sound quality to OCXO clocks. I have never seen anyone else in the high end audio industry even say they have tried SAW clocks.
Unfortunately the Oppo mainboard itself died and all those mods (like a full on R-core LPS powering the mainboard) turned it into a paperweight. It was a way better sounding transport than any entry or medium level product you can get now.
Spend your money on a good DAC that includes a good clock. Spending thousands on a clock is a huge waste of money, IMHO.
As mentioned earlier, the main purpose of an external clock is to synchronize multiple devices, not to improve sound quality.
If there is an improvement in sound quality, it's going to be much less than you could have realized by putting your money into a great DAC. Lipstick on a pig and all that...
The issue with S/PDIF or AES "reclockers" is that you have two clocks arguing over what should the absolute clock rate be.
The DAC is forced to take one of two approaches: Abandon it’s internal clock or attempt to keep it’s internal metronome and "fix" upstream deviations from it’s own mechanism. This is exactly the thing pro clocks do, but only because there are upstream devices manipulating the data stream. They are there to stop an inevitable argument that arises as a result of a studio’s workflow. Home users HAVE no such arguments to solve, but can create them by adding upstream clocks.
Maybe the best of these situations is to use an Asynchronous Sample Rate Converter, like in the Schiits, but then you’ve got to deal with the fact that your DAC is no longer being given bit-perfect conversions.
In measurements done, I’ve seen original DAC jitter perform actually get degraded, and the signal looks like the upstream jitter PLUS the DAC’s original jitter signature.
Either use an integrated streamer/DAC or a streamer with a multi-second buffer plus USB / asynchronous communication with the DAC is the way to go IMHO.
I should point out, use whatever you want to which sounds good to you, but so far all I'm reading is a misunderstanding of how and why studio clocks work. I'm going to go with the documentation from Benchmark and Mytek and say it's a bad idea.
for avoiding misunderstandings: In my case Dac, Etherregen and USB reclocker are all synchronised to the same Antelope 10m clock. When using AES or SP/DIF the DAC needs to rely on the incoming embedded clock signal whereas USB asychronous slaves the server‘s clock, so effectively my server is equally synchronised to the 10m clock.
The issue with S/PDIF or AES "reclockers" is that you have two clocks arguing over what should the absolute clock rate be.
The DAC is forced to take one of two approaches: Abandon it’s internal clock or attempt to keep it’s internal metronome and "fix" upstream deviations from it’s own mechanism.
How does the DAC know? What do you mean by 'abandon it's internal clock'? Are you talking about the external clock input of a DAC substituting its internal one? Don't you agree that the better (more accurate with less jitter/noise) the incoming data on AES/SPDIF, the easier the job of the DAC's internal clock?
@greg_f There are two different ways of dealing with S/Pdif. One, very common way, is to adjust D/A clock to average frequency of incoming S/Pdif stream while another is to completely ignore S/Pdif clock, strip the data and send it to D/A converter at different rate (Asynchronous Rate Converter).
In first case data is often oversampled being sent to D/A converter in exact multiples of received frequency, while in the case of Asynchronous Rate Converter, D/A conversion frequency and incoming signal frequency are independent. My Benchmark DAC3 D/A converter runs always at 210.9kHz - no matter what signal frequency is (it was 110kHz in DAC1).
CDP output data can be buffered and sent at exact intervals since both buffer clock and motor speed come from the same source (quartz crystal), but receiving D/A converter has to be somehow synchronized, otherwise samples may be lost. In older devices it was Phase Lock Loop (PLL) analog circuit adjusting Voltage Controlled Oscillator (VCO) - D/A conversion clock. These days everything is digital, so PLL circuit is also likely digital. Either way, in this scheme D/A conversion rate is not constant, but adjusted to average frequency of incoming S/Pdif stream.
@kijankiThanks for the explanation. My DAC is an older Weiss DAC202 that uses ARC. It has extensive fairly advanced PLLs (it uses a wider range digital PLL (I don't know its noise/jitter spectrum) and its output is fed to an further analog PLL to reduce the jitter of the first PLL. I believe both PLLs are implemented on a single DICE IC which was state of the art back then. I used to have a datasheet but I must have lost it during a move so I uncertain of the exact operation. The DAC uses older ESS converters and I think they always run at 1.536MHz. To complicate the clocking scheme further, the AES output of my source feeds a Trinnov ST2 Hifi (digital room correction device) which also uses a DICE generated clock and its AES output then goes to the DAC. I need to refresh my memory!
My issue is that my DAC doesn't have a USB i/f and therefore I need a streamer with either an AES/SPDIF output or an additional DDC to convert the USB.
@greg_f I remember that Weiss DACs had Firewire. I had Firewire HDs with my old Mac computer and used them with the newer generation with an adapter. Advantage of Firewire was that it had, being extension bus, sustained bandwidth. Peripheral buses like USB don’t have that running under protocol. This sustained bandwidth made it very popular in Audio/Video industry. The great feature of Firewire - Direct Memory Access (DMA) killed it. Once somebody made pocket Linux to run on the phone it made it dangerous. Hackers could connect it to portal in large company and bypass (or even obtain password).
You can try it. Other than that you have only choice of coax or Toslink. I use Toslink because of my DAC’s very strong jitter suppression to avoid electrical noise injection and possible ground loops. On the negative side Toslink drivers have slow edges making it noise susceptible (noise on the edge modifies threshold point affecting timing). Toslink works better when system is clean of electrical noise. Faster edges of coax are less sensitive to noise but create another problem - reflections from characteristic impedance boundary. You need to use impedance matched cables possibly 1.5m or 2m long (to make first reflection miss original edge) or very short cable, Rule of thumb is that transmission line effects (reflections) start when propagation time one way is longer than 1/8 of transition time. For typical 25ns transition 1/8 is about 3ns making it 0.6m cable (assuming 5ns/m). Since it includes all wiring inside on both ends I wouldn’t go further than a foot. The shorter the better. As for the conversion from USB - that might be good, especially if it contains electrical isolation.
@kijankiThank you for the response. I enjoy reading your replies since you seem to understand electronics better than most on this site. Sometimes it is difficult to have a technical conversation with people who have little knowledge even about the basic concepts but they call themselves experts. I find audio a strange field... Your analysis on transmission line is spot on. For spdif I rather have proper 75 Ohms BNC terminated cable than with RCA plugs, I had an argument with somebody who was saying it is only audio, there is nothing high frequency so no need to worry about reflections, what he forgot is that reflections are caused by the rise/fall time of the edges and not the waveform frequency or data rate. Anyway, I diverted :)
Yes, yes, I much rather use Firewire than USB, in fact I still use a PC (with very little optimazation) with a PCIe Firewire card into the Weiss. But Firewire is getting old and new device of course don’t support it. I also use the Weiss AES i/f which is not too bad, almost as good as the Firewire. As I am interested in Qobuz, my next purchase is going to be a streamer, the way I see it is either fully optimize my server (both hardware and software), use the Firewire card and hopefully find some software that will support it, or buy a relatively decent streamer like Lumin/Innuos/Aurender and possibly a DDC as USB look like being the most common i/f these days. Unfortunately where I currently live there is no way to demo anything so I have to buy by what I read on forums and reviews... not the best way.
This thread has become a full time job, with terrible work life balance and benefits so I'm checking out after pretty much saying everything that I felt I needed to share.
@kijankiYeah, I think AES will be. Now I need to find a good streamer with AES output up to 4,000 Euro. I have been going round and round this subject for far too long without making a final decision...
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 🙄
Although I rarely post over here I have read quite a few of your views and I respect your views and experience. Having said that you are saying my views are based on 'documentation' (whatever that means) and no direct experience. Ok if that's what you think. You have your opinion, I have mine and in this instance we disagree. Btw I don't dispute what you are hearing. It's all good.
no harm done, I just wonder why people advocate S/PDif or AES EBU connections which depend on the server‘s clock which is often the weakest link when all the new chip set development has gone into asynchronous USB which slaves the server‘s clock thus obviating the problem….
I said I am out of this thread but I will answer you.
In my case I have an older DAC that is still excellent and I am reluctant to change it but it doesn't have USB i/f. therefore I am looking for AES or SPDIF i/fs. You say USB is the better i/f and you could be right but I think it really depends on how the DAC has implement the i/fs. With some DACs I still prefer AES over USB. Also some DACs are agnostic of the interface (please see kijanki's explanation further up this thread.
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.
