• WARNING: Tube/Valve amplifiers use potentially LETHAL HIGH VOLTAGES.
    Building, troubleshooting and testing of these amplifiers should only be
    performed by someone who is thoroughly familiar with
    the safety precautions around high voltages.

Tube SPDIF output

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Well there we go, then! A 6CH6 is indeed designed for 75 ohm video lines. Perfect for SPDIF. :)
Ayon has made a Network Transport (a network music player) with "Vacuum-tube buffered digital output stage". The data sheet says "6H14 tube (digital output - signal buffer)" Network-Transport : Ayon Audio
Is this SPDIF design really bad ? :)

(the Ayon CD-T is using also 6H14, but that's not important for me... :) http://www.ayonaudio.com/products/cd-player-dac/cd-player/cd-t.html)
 
Last edited:
nope, im profesional electronic specialist. i measured diferences on both spidif outputs.rise times, overshoots and etc.
original has about 8ns rise time , tube out has only 4.5ns, tubehas more ringing on flat ,but thats not important, becouse dac reads only "rise,drop" fronts of signal.
On MCU originaly was also 4.5ns rise time. sooo.... ? tube is like speed of light ....:D
 
do not agree, please study spdif protocol more closely, the faster signal rise, the less jitter is generated.plus dac is no more "quesing " it was 0 or 1,so data decoder is disbaling "data correction" algorithm
And ofcourse bad cable is bad in all situations, lets asume its good cable is used;)

This assumes that the faster risetime is preserved throught the signal chain.

Unless the cable is correctly matched and terminated with a correct load impedance (or source impedance if serially terminated), if the driver risetime is too fast, then ringing will occur at the receiver end, and maybe at the driver. That ringing at the receiver could cause further timing errors which defeat the original objective of trying to ensure accurate timing.

The problem is that many people think of S/PDIF as a solely digital signal. In the final analysis, digital signals still obey the laws of physiscs, and they dictate that signals with fast risetimes need correct handling to preserve timing details and to avoid overshoot / ringing if they are significant to the application.
 
Lowrideris said:
do not agree, please study spdif protocol more closely, the faster signal rise, the less jitter is generated.plus dac is no more "quesing " it was 0 or 1,so data decoder is disbaling "data correction" algorithm
No data correction takes place after SPDIF, so nothing to 'disable'. All you get is parity, so you either use or discard the data. An SPDIF implementation would have to be very bad to corrupt the data so badly that it fails the parity check.

Too fast slew rate can give rise to greater cable-related jitter, as I said. The details depend on things like cable length and how resistive the termination is at all frequencies. Basically, if you put a faster slew rate in then you must hope that the terminations remain correct up to higher frequencies. Obviously too low a slew rate causes trouble for the receiver data slicer.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.