S/Pdif to lightpipe digital patchbay?
- Thread starter BasPer
- Start date
And I keep a constant vigilance desperately trying to stay away from any asycronous logic. Hm, maybe. But I'm not sure. One asycronous device I can deal with, and I don't think the times when you have more than one are that common. Synths may be a problem, but I wouldn't know 'cause I'm not into that kind of thing. I would rather feel comfortable knowing that my patchbay isn't doing a lot of half-assed sample rate conversion, but is only sending out what it gets in.skippy said:
Then on the other hand the Crystal CS8420 is supposed to be quite good, and is probably only about $15 in quantity. (It's $40 a pop at my local chip-pimp.)
skippy
New member
Hey, another nerd! Pleased to meet you... I've been involved in silicon design for the last 20 years or so, although these days I'm doing more ASICs and fewer full-scale custom processor designs than in years past.
Times change. Luckily, there's still a need for polygon-pushers. Keeps the lights on!
Trying to explain synchronization failure in the context of music is a very strange sensation. But most folks never get the opportunity to find out _why_ some of these nerdy things go wrong, so I like to think that threads like this serve a bit of a purpose.
Times change. Luckily, there's still a need for polygon-pushers. Keeps the lights on!
Trying to explain synchronization failure in the context of music is a very strange sensation. But most folks never get the opportunity to find out _why_ some of these nerdy things go wrong, so I like to think that threads like this serve a bit of a purpose.
Coolness! I have only been working full time in electronics for three years. I started out as a physicist drawing rectangles, but as processes and IPs have gotten better we do less and less by hand and more and more by synthesis, so I've gradually become a Verilog hacker! Heed my advice and stay clear of that sorry-excuse-for-a-language! 
(By the way, my ASICs bigger than yours!
)
(By the way, my ASICs bigger than yours!
)For the record, I solved my own S/PDIF problem using a 40 buck radio shack A/V switching box.
The S-video connecters are 75 ohm...perfect! Hooked all the pres and pods etc up to the Radio Shack box going to an m-Audio CO2 and the CO2 up to the sound card via a lightpipe.
I have checked for bit depth truncation and all is fine!
So, no need for the now slightly suspect M-audio Digipatch or the down right defective ST audio digital patch bay and I’m nearly 400 bucks richer !
Cheers all
S
The S-video connecters are 75 ohm...perfect! Hooked all the pres and pods etc up to the Radio Shack box going to an m-Audio CO2 and the CO2 up to the sound card via a lightpipe.
I have checked for bit depth truncation and all is fine!
So, no need for the now slightly suspect M-audio Digipatch or the down right defective ST audio digital patch bay and I’m nearly 400 bucks richer !
Cheers all
S
Yep, thats the way to do it, if you only need to switch between some inputs! (And you needn't worry about truncation because there is nothing going on inside that box that you can't check with an ohm-meter.)
Congratulations! Now go spend the leftover cash on something useful like beer or a bass guitar! Or a crate of Gammeldansk perhaps; would last you a lifetime...
Congratulations! Now go spend the leftover cash on something useful like beer or a bass guitar!
Or a crate of Gammeldansk perhaps; would last you a lifetime...Well Im playing a Peavey Cirrus 4 string through a Bass Pod at the mo so It looks like its the Gammeldansk ! Teee Heee !!!
Looks like its falling over, dribbling and hitting things with a big stick time!
Looks like its falling over, dribbling and hitting things with a big stick time!
skippy
New member
Good move!
This points out an extremely important item, and one that is often overlooked: the coaxial and optical representations of S/PDIF/ADAT aren't _quite_ the same items, even though the exact same _bits_ are being sent. The coaxial form is sent over 75ohm coax with proper line drivers, and it has *enormous* bandwidth (several hundred MHz if done with care, and certainly at least 50MHz even if done by a complete wanker): doing 2 channels of 24/44.1 is an absolute walk in the park for both the send and receive hardware, since you only need 1.15MBit/sec to do it.
Optical is another story, on the other hand. The TOSlink hardware (the transmitter and receiver devices themselves that launch the optical signal up the fiber and receive it) was designed for 2 channels of 16/44.1, and there's very little bandwidth margin above that requirement. Everyone always thinks of fiber has being higher bandwidth, and it certainly *can* be: but those particular consumer items were designed for absolute minimum cost, not any real performance target.
Here are the datasheets for the Toshiba TOSlink stuff (they originated the hardware, and are by far the most commonly used):
http://www.toshiba.com/taec/components/Datasheet/TOTX173.pdf and http://www.toshiba.com/taec/components/Datasheet/TORX173.pdf
Max data rate is spec'd as 6MBit/sec. Let's see: 8 channels of 24/48 data is 9.22MBit/sec: so you are running the hardware at 150% of its design max *right off the bat*...
Yow. No wonder cheap optical patch systems have problems with ADAT. In order to make that work at all, IMNSHO you really need to receive the data, reclock it, buffer it, and _then_ send it out with corrected timing and framing. In my opinion you cannot just connect a transmitter behind a receiver, shove the raw signal back out again without reclocking, and just hope for the best... Running that far above the bandwidth spec has to smear the edges of the pulses all to hell and gone in the time domain, and doing it twice back to back would leave you with _mud_. I suspect that that is why the Midiman design (and others) have problems with Type II ADAT: after you go through 2 send/recieve pairs, the lower bits probably fall so far out of frame sync that they go the way of the dodo. It'd be interesting to try looping through one of those 2 or 3 times, and seeing how many bits might still be seen wiggling on the other side of the final receiver! The cumulative timing errors would be interesting...
Anyway, what the Z-Sys box does is all that resyncing and buffering, and that's why it is more expensive.
So if you want to do _really_ cheap S/PDIF switching, then doing it in the 75ohm, coaxial domain certainly makes much more sense: the extra bandwidth buys you a ton in terms of data integrity, and therefore reduces the need for magic to be done to preserve it!
This points out an extremely important item, and one that is often overlooked: the coaxial and optical representations of S/PDIF/ADAT aren't _quite_ the same items, even though the exact same _bits_ are being sent. The coaxial form is sent over 75ohm coax with proper line drivers, and it has *enormous* bandwidth (several hundred MHz if done with care, and certainly at least 50MHz even if done by a complete wanker): doing 2 channels of 24/44.1 is an absolute walk in the park for both the send and receive hardware, since you only need 1.15MBit/sec to do it.
Optical is another story, on the other hand. The TOSlink hardware (the transmitter and receiver devices themselves that launch the optical signal up the fiber and receive it) was designed for 2 channels of 16/44.1, and there's very little bandwidth margin above that requirement. Everyone always thinks of fiber has being higher bandwidth, and it certainly *can* be: but those particular consumer items were designed for absolute minimum cost, not any real performance target.
Here are the datasheets for the Toshiba TOSlink stuff (they originated the hardware, and are by far the most commonly used):
http://www.toshiba.com/taec/components/Datasheet/TOTX173.pdf and http://www.toshiba.com/taec/components/Datasheet/TORX173.pdf
Max data rate is spec'd as 6MBit/sec. Let's see: 8 channels of 24/48 data is 9.22MBit/sec: so you are running the hardware at 150% of its design max *right off the bat*...
Yow. No wonder cheap optical patch systems have problems with ADAT. In order to make that work at all, IMNSHO you really need to receive the data, reclock it, buffer it, and _then_ send it out with corrected timing and framing. In my opinion you cannot just connect a transmitter behind a receiver, shove the raw signal back out again without reclocking, and just hope for the best... Running that far above the bandwidth spec has to smear the edges of the pulses all to hell and gone in the time domain, and doing it twice back to back would leave you with _mud_. I suspect that that is why the Midiman design (and others) have problems with Type II ADAT: after you go through 2 send/recieve pairs, the lower bits probably fall so far out of frame sync that they go the way of the dodo. It'd be interesting to try looping through one of those 2 or 3 times, and seeing how many bits might still be seen wiggling on the other side of the final receiver! The cumulative timing errors would be interesting...
Anyway, what the Z-Sys box does is all that resyncing and buffering, and that's why it is more expensive.
So if you want to do _really_ cheap S/PDIF switching, then doing it in the 75ohm, coaxial domain certainly makes much more sense: the extra bandwidth buys you a ton in terms of data integrity, and therefore reduces the need for magic to be done to preserve it!
Robert Tielke
Member
Thanks, interesting information. I am currently working on this too and need to understand more about S/PDIF.
I am using a ADAT like bundle of sigs to transmit data. I got inspired by this
MIDI over S/PDIF and ADAT- musical high speed interface
I am using a ADAT like bundle of sigs to transmit data. I got inspired by this
MIDI over S/PDIF and ADAT- musical high speed interface