wayne325

Saying BNC is "exactly" 75 ohms (assuming it's the 75 ohm type) is going a fair bit too far. It's like seeing that the mfr says your car engine produces 256 bhp, and you conclude that your engine therefore produces 256 bhp. The real answer would be more like "somewhere between 240 and 270 bhp" (and of course it would change with a dozen or so different parameters). Connectors have impedance discontinuities. All one can do is reduce it as much as possible. Also the cables aren't 75 ohms exactly either. Specs for these parts are typically +/- 10% or so. Once a connector system has been chosen, it's all about the materials and ability to control tolerances at manufacturing. There are machines called "time domain reflectometers" that measure impedance of a cable as a function of the position along the cable and connectors. Having said this, is a given BNC cable probably better than, say, an RCA connected cable as far as reducing reflections is concerned? Heck, ya. In the end, if the DAC and transport are wired up the right way, as I wrote many posts ago, the cables just don't matter as long as they make an electrical connection. You could use a lamp cord on SPDIF and it would work just fine. Might radiate a bit, :-) but you'd not be able to tell in a listening test against a $2000 cable which was which. For the record, the $3 cables I wrote about earlier are BNC.

I have a system where the DAC sources the clock to the transport. This way the jitter to the transport and back are immaterial. The data is read out of a buffer in the DAC that is clocked by the system clock source. The jitter going into that buffer is immaterial unless it's so bad the buffer overflows or underflows (64 bytes - not gonna happen) which results in data errors which would be probably quite easily audible as clicks. The only jitter in the audio stream that I'm left with is the inherent jitter in the physical clock device, and the electronics from the clock to the DAC chips plus the DAC chips themselves. I used isolators between the clock and DACs chips, plus each has its own regulated power supply (clock, digital electronics, DAC chips left and right, analog left and right), further minimizing jitter and crosstalk. Two devices that are syntonized think 1/T (=F) is the same. Two devices that are synchronized think T is the same. You want your DAC and transport syntonized. Wireless basestations must be synchronized (else handoffs don't work).

As I lead off in my first post, knowing little about a topic usually is no barrier to postings. Can't even bother to do a google search on the topic before posting eh guys? Here is a link to the first search result and - wonder of wonders !!!!! - the words syntonization and synchronization BOTH appear and they are different things and for those who can read and understand, it will become clear that all this time you've been saying "synchronous", you really meant "syntonous". http://www.ines.zhaw.ch/fileadmin/user_upload/engineering/_Institute_und_Zentren/INES/Downloads/IEEE_ISPCS08_Sync_in_HW.pdf In short, two boxes that are SYNCHRONIZED think it is the same time. That is, one SYNCHRONIZES one's watch to another. Now contrast this to what a transport and DAC are trying to achieve - they are trying to think that they have the same FREQUENCY, not the same TIME. There is no protocol or method whereby the DAC and transport are negotiating to figure out what TIME it is over SPDIF. The fact that the discussion is jitter does not change the fact that the discussion is about syntonization. The two are very simply related: frequency = 1/time. In fact, jitter is all about ensuring that the change in FREQUENCY has a spectrum that has small amplitude in the audio band of FREQUENCIES. We measure jitter as frequency spectrum of time distortions. But we've digressed quite a bit. In the end, a "synchronous" interface is one which has a clock and data signal. The interfaces listed as "synchronous" do not all fit this description (eg SPDIF is a data-only interface, the clock is recovered at the receiver).

Well, for starters, we're not even using the correct word. We're writing "synchronous" where we really mean "syntonous". But that's common language usage. What's the difference? Syntonous has to do with frequency. Synchronous has to do with time. We're talking about frequency, not time. Another issue, and choosing a particular example, there is no difference in the INTERFACE between full duplex Ethernet and SPDIF, although these are described as being different beasts as far as the type (synchronous/asynchronous) of interface is concerned. In both, the reciever must regenerate a clock in order to recover the received data. The best architecture is for the DAC to send clock to the transport, and the transport to send data back to the DAC syntonized with that clock. This way the DAC chips can be run right off the clock itself. There is no cleaner way to clock the system. I couldn't find any systems that do this so I built my own DAC that does this and I use a Transporter in "clock input" mode slaved off the clock that is driving the DAC chips. I use $3 cables for both the clock and the data, and no-one who has tried can hear a difference between the $3 cables and multi-hundred dollar cables substituted. One listerner said it was very easy to tell, then when we did a blind test, he scored - you guessed it - 50% on the test (for the mathematically disinclined, that means he had no clue which cable he was listening to when tested if he didn't know the correct answer already). The cable marketing bunk quoted in the first post is mixing up bit errors with jitter, trying to scare one into buying their cables with the (mistaken) thought that it will be much better if there are no errors in the data stream.

Wireworld are simply trying to sell you a cable that is overpriced. It never ceases to amaze me how poeple who have no knowledge of a topic don't allow that to stop them from posting answers to questions. Indeed, the quote from Katz is not even correct. Oh well.

You don't need to have an external box to achieve modularity. The same can be had by using a daughterboard and enough foresight (or luck) that the mechanicals and connector scale with any future developments of the clock.

Gordon wrote: "It is however possible to overflow Steve's design and that is why many companies use what are called frequency synthesizers. These have a great deal of range to pull in on but at the price of 50-100 times more jitter at the Master Clock which means tons of jitter at the interface." I've seen implementations of loop filters that have two different filters and a lock detector. WHen the loop detects it is out of lock, it uses a wideband filter transfer function that as you correctly point out results in a fairly bad jitter spectrum. When lock is achieved, a different narrowband loop filter is engaged and this filter has a much better jitter transfer function. First seen by myself on asynchronous 570 Mbps fiber transport system at my first job out of skool. But I've seen the same thing since and described in other applications. No reason it wouldn't work here. Also.... why are we talking about clock synthesizers that have 3 discrete frequencies and switch amongst them to try to keep a buffer at a target fill level? Why not just use a nice narrowband filter controlling a VCXO, controlled by the fill level of the buffer? THen you have a continuous frequency change of some transfer function rather than step functions. I fixed this whole schmozzle myself rather like the Ferdinand Porsche method: "I didn't see a DAC on the marketplace I liked, so I built one myself". Main issue is it's not generally applicable because it was specifically designed to work with the word clock input of a Transporter, which it does very nicely. Rather a big job though, making your own DAC. Interesting thing - I did a blind test of digital cables in the clock loop with a friend. As one would guess ahead of time, we couldn't tell the difference between a $300 digital cable and a $5 one. Sux to the the guy that bought the $300 cable (it wasn't me :-) ) Hey I just had a brilliant idea. I'll bet $10,000 with ANYONE who thinks they can tell the difference between my $5 digikey BNC cable and any cable they want to test it against in my system. Note that "tell the difference" means during a blind test. If you know the answer ahead of time, we call that "cheating" where I come from.

Mani, Transmitting a word clock (from the transport to the DAC) is the wrong way around. You want to generate your high quality clock in the DAC and slave the transport to the DAC. This is the best possible situation, all else being equal. You then buffer up the data from the transport a little bit, which gets rid of all jitter that is not in the clock path and takes the transport and all cables out of the sound quality equation since all the transport now has to do is deliver the correct data to the DAC and the clock in the DAC is responsible 100% for all the jitter and time accuracy. I'm not saying this arrangement is the best in all cases because then you get down to arguing about IMPLEMENTATIONS. But it is the "correct" architecture and it is why all the interest in async mode USB DACs.

The new DAC was not isolated and the old one was isolated. THat is why the difference. When I made my DAC I isolated the S/PDIF inputs using a small transformer designed for telecom equipment for DS3 signals. Alas what "should" be and what are, often are two different things. Oh, and, BTW your UPS is now not grounded and is at risk to do all sorts of damage under fault conditions. You're playing with fire. What I'm saying is, you have not solved the problem as you seem to think you have. You have simply masked it by causing another problem somewhere else.

One thing we can all be sure of, having observed the high tech industry over the past 25 years, is that software / hardware/ information will never improve and hi-res digital is many decades in the future, if it ever occurs at all. For the humor-challenged, yes that was a joke.