Reclocking the SPDIF line

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Schmitt triggers stink because......

It uses hysterisis. It couples large amounts of crud back onto the line whenever it slams form one extreme to the other. So, you basically have what could amount to a short circuit reflected back to the load.

You need a very linear stage coming right off of the line. After that, you can go into something like an '04 gate to square things up.

Long ago......I ran some tests on what brand of HC logic reflected less crud back to the input for standard configurations. Unfortunately, I have forgotten it. But with all the ownership changes in the 12 years since, it may not be current anyway.

I do remember that the lowly Yamaha YM3623(?) RX had a very low amount, lower than most brands. No idea why.

Jocko
 
Hi Tieftoner,
Sorry I mixed up two threads.
I meant Doede Douma and this is his DAC:
http://www.dddac.de/ma_dac21.htm
Perhaps he is doing what you like to do.....

Elso - THANK YOU! That is exactly what I was wanting to do! I have read through the CS8412 datasheet to see how the mode settings were in relation to the CS8414 datasheet. The mode section is identical, word for word regarding Format #11. Doede did exactly what I was hoping would be possible, and his DAC works... so the mode must actually be possible with these DIR's. I'm very excited and will now move on into doing a schematic layout... then comes the PCB drawing for a home-made trial run. :)

Doede also had a switch that controlled the DIR from using two different modes for an A/B comparison. the first uses the clock recovery circuit within the CS8412, and the second switches to the Format 11 that takes the input from a local, low-jitter clock -- he uses the Guido Tent clock. I too will implement this same switch... but I plan to use the Kwak clock.

Thanks for all your help to everyone.

Jocko, Thanks for the explanation on the Schmitt triggering problem.

Wish me luck :)
 
Um, well, he's reclocking the bit clock and word clocks, but he isn't using mode Format #11... he's using the I2S input format to get the external clocking data. Sorry if I have created confusion. Nonetheless, it is still compatible to the CS8414's that I have, so I will give it a shot.

Today, I worked on the schematic layout by hand, made a differential 2 pole low-pass multiple feedback filter to convert the differential outputs of the CS4396 to a single ended output, worked on a reset circuit for the DAC and DIR, and a relay shorting the outputs to get rid of any transient noise during turnoff/turnon and when the DIR loses its lock. I plan to use the AD8610/20 for the output filters. Does anyone have strong feelings about using the single version over the dual? Is crosstalk really that serious of an issue with them? I suppose it doesn't hurt to do dual singles, it's not like I'm trying to greatly reduce PC board real-estate in a mass production unit here...

So, again, sorry if I created confusion - I just wanted to set things straight.

Thanks all for the participation -
 
Somebody used this before:

CS8412 has also some specific predefined behaviours in case the SCK and FSYNC clocks are asynchronous to the input flow. In case a new word is requested by FSYNC clock before a new one has been read, an error flag is raised, but there is no "hole" in the output data flow: the old sample is re-output again.

See http://www.tnt-audio.com/clinica/convertusdecdig_e.html

Anyway,

If you have a source with a clock which is slower than the DAC's, you will get double samples into the DAC. If you have a source with a faster clock, you will loose samples from time to time.

But it can still sound better than the normal jittery connection......

If you want to get around this: use a pll or feed the clock back to the transport.

Greetings,

GuidoB
 
Re: ASRC sound

Mark Hathaway said:
Howdy guys,


I must say, I'm working with both the cs8420 and ad1896, and they do good things. An ad1896 with a kwak clock sounds amazing.

The ad1896 is the clear winner of the two, just wish it had a hardware mode.

Mark Hathaway

Mark and anyone else here, don't bother with CS8420. This ASRC
is well behind performance of AD1896 and every dac I've heard
with one sounded washed out.
TI have just brought out a new ASRC, not sure what the number
is, have to check their website. Anyway, it betters 1896 although
there is no info on data sheet WRT jitter attenuation corer freq.
1896 is close to 1Hz which is excellent. Anyone know any TI app
egineers?? From memory, I believe one of the new TI ASRC is
hardware mode only device. If you check the FFT's they are
quite unbeleivable. Even at 0dBFS IP, the "grass" is down at
-160 and just about nothing else to be seen. How this equates
to sonics we will find out.... they all have brick wall filters...
and 0 x OS TDA1541 is sounding very good to my ears!

Cheers,

Terry
 
Re: Schmitt triggers stink because......

Jocko Homo said:
It uses hysterisis. It couples large amounts of crud back onto the line whenever it slams form one extreme to the other. So, you basically have what could amount to a short circuit reflected back to the load.

You need a very linear stage coming right off of the line. After that, you can go into something like an '04 gate to square things up.

Long ago......I ran some tests on what brand of HC logic reflected less crud back to the input for standard configurations. Unfortunately, I have forgotten it. But with all the ownership changes in the 12 years since, it may not be current anyway.

I do remember that the lowly Yamaha YM3623(?) RX had a very low amount, lower than most brands. No idea why.

Jocko

Jocko,

I've heard you mention this many times, it's not falling on
deaf ears in this case!
I just did some work on a Marantz DA12. It did have a discrete
front end driving receiver chip, which someone had changed and
completely stuffed up. I restored the discrete section and put a
discrete high speed follower after it to drive cable to receiver.
This worked beautifully feeding the receiver a textbook perfect wave form.

Cheers,

Terry
 
Re: Re: Schmitt triggers stink because......

Terry Demol said:


Jocko,

I've heard you mention this many times, it's not falling on
deaf ears in this case!
I just did some work on a Marantz DA12. It did have a discrete
front end driving receiver chip, which someone had changed and
completely stuffed up. I restored the discrete section and put a
discrete high speed follower after it to drive cable to receiver.
This worked beautifully feeding the receiver a textbook perfect wave form.

Cheers,

Terry
Hi Terry,
Any schematic?
Or is it just a one transistor emittor follower? Is it at the DAC(receivers end) or at the CD players end?
Thanks in advance.
Interestingly when I did a search for cable drivers and receivers I found the receivers seem all to use Schmitt triggers!
Elso/only using SPDIF for satellite receiver
 
Re: CS8412 Musings

Elso Kwak said:

I know (or better, i heard from saying, not from experience)

Or eliminate the problem: clock at dac with feedback to player. Async Fifo on the incoming signal(s).

It then should not matter that there is a spdif connection before the fifo or that it is a direct i2s connection. (toch?) Clock is at the DAC and the data is clocked out of the fifo on this clock.

If the filling of the fifo is jittery, so what. It has two async clocks.

You know, i think, that i'm working in this (slowly).

GuidoB
 
quote:
Originally posted by guido
If you want to get around this: use a pll or feed the clock back to the transport.
Greetings,
GuidoB

Hi Guido,
Still better: I2S Direct. SPDIF is crud(e).
http://www.diyaudio.com/forums/show...9220#post249220

Elso, no denying that it's better. I'd like to have a pretty decent DAC that doesn't require the modding of a player though. Guido makes a good suggestion. Essentially, if the masterclock from a high-quality, low-jitter clock like the Kwak clock is sent back to the player, it would be as good as I2S directly from the player, wouldn't it? I think that would be an interesting comparison. Okay, no Jocko, I'm not ignoring you... there would be the inopportune reflections and problems with regard to the DIR. I guess I digress.... Still, it should be a considerable improvement, I surmise.

Terry: Yes, I've heard some great hype about the new TI ASRC's. I think they are the SRC4192 (hardware control) and SRC4193 (software control). I have some samples on order, but they are on back-order. Leave it to BB to use the SSOP package to annoy us DIY PCB makers... Oh, and the performance... WOW. The "grass" is indeed below -160dB... about -175dB with a -60dBFS 1kHz input! THD+N of -140dBFS... flat line with an input amplitude (1kHz) of -140dBFS to 0dBFS! That's pretty impressive stuff...

Somebody used this before:

CS8412 has also some specific predefined behaviours in case the SCK and FSYNC clocks are asynchronous to the input flow. In case a new word is requested by FSYNC clock before a new one has been read, an error flag is raised, but there is no "hole" in the output data flow: the old sample is re-output again.

See http://www.tnt-audio.com/clinica/convertusdecdig_e.html

Anyway,

If you have a source with a clock which is slower than the DAC's, you will get double samples into the DAC. If you have a source with a faster clock, you will loose samples from time to time.

But it can still sound better than the normal jittery connection......

If you want to get around this: use a pll or feed the clock back to the transport.

Greetings,

GuidoB

I realize that there will be drop outs from time to time. But, this is more of an educational experience.... like Jocko always says... just build the darn thing. I'll never know for myself until I try it. That's why I'm going to implement the switch to be able to use either the direct clocks from the CS8414 or the reclocked data. Can't knock it 'til I try it... I appreciate your comments though!

Like I said, one of the objectives of this was to be able to hook it up to any player with an SPDIF output. I'd like to make a version that I can build for friends that won't want me to rip apart their players.... or rather that I don't want to spend 10 hours figuring out how do mod each one of thier players ;)

Thanks all for the comments,
 
Clock Transport

Tieftoener said:


Elso, no denying that it's better. I'd like to have a pretty decent DAC that doesn't require the modding of a player though. Guido makes a good suggestion. Essentially, if the masterclock from a high-quality, low-jitter clock like the Kwak clock is sent back to the player, it would be as good as I2S directly from the player, wouldn't it? I think that would be an interesting comparison. Okay, no Jocko, I'm not ignoring you... there would be the inopportune reflections and problems with regard to the DIR. I guess I digress.... Still, it should be a considerable improvement, I surmise.

Terry: Yes, I've heard some great hype about the new TI ASRC's. I think they are the SRC4192 (hardware control) and SRC4193 (software control). I have some samples on order, but they are on back-order. Leave it to BB to use the SSOP package to annoy us DIY PCB makers... Oh, and the performance... WOW. The "grass" is indeed below -160dB... about -175dB with a -60dBFS 1kHz input! THD+N of -140dBFS... flat line with an input amplitude (1kHz) of -140dBFS to 0dBFS! That's pretty impressive stuff...



I realize that there will be drop outs from time to time. But, this is more of an educational experience.... like Jocko always says... just build the darn thing. I'll never know for myself until I try it. That's why I'm going to implement the switch to be able to use either the direct clocks from the CS8414 or the reclocked data. Can't knock it 'til I try it... I appreciate your comments though!

Like I said, one of the objectives of this was to be able to hook it up to any player with an SPDIF output. I'd like to make a version that I can build for friends that won't want me to rip apart their players.... or rather that I don't want to spend 10 hours figuring out how do mod each one of thier players ;)

Thanks all for the comments,

Hi Tieftoener,
Basically I am using a NON-OS DAC. This implicates I don't need the masterclock in the DAC. So why sending it from the DAC to the transport? And this is DIY. Three cables, or four with deemp, don't bother me. I want the ultimate in sound quality.
In my player DAC combination I omit a lot of chips and a PLL using I2S direct. Guido is doing a great job constructing a FIFO. This is way over my head. I can only think out simple schematics...
With the flip of a switch I can compare SPDIF with I2S direct. The switch is located as a two way for the I2S signals just prior to entering the DAC (TDA1543). In all honesty the CS8412 is not bad but you loose some quality. But I had to implement a lot of stuf for the CS8412: DIR with resetcircuit, AD8561, digital +/-5V supply, low noise +5V analog supply (for PLL).
:bawling:
 
Understood... I'm not denying yours is a better approach, but one of the purposes of my project here is to be compatible with any player with an SPDIF output.

I'm assuming you're using your Kwak clock inside the player though, to send the master clock to the main decoder chip on the player that outputs the I2S signals. Is this a false assumption?

Whether or not you have a Non-OS DAC with my proposed setup, one would still benefit by the your low-jitter clock controlling the output of the CD decoder chip. Also, this would sync the player outputs that go to the SPDIF transmitter with the "reclocking" circuit on the outpboard DAC. This would complicate things too much for what I want to do, and as you say, one would be better off to just output the I2S signals individually.

thanks Elso,
 
SPDIF & I2S Direct

Tieftoener said:
Understood... I'm not denying yours is a better approach, but one of the purposes of my project here is to be compatible with any player with an SPDIF output.

I'm assuming you're using your Kwak clock inside the player though, to send the master clock to the main decoder chip on the player that outputs the I2S signals. Is this a false assumption?

Whether or not you have a Non-OS DAC with my proposed setup, one would still benefit by the your low-jitter clock controlling the output of the CD decoder chip. Also, this would sync the player outputs that go to the SPDIF transmitter with the "reclocking" circuit on the outpboard DAC. This would complicate things too much for what I want to do, and as you say, one would be better off to just output the I2S signals individually.

thanks Elso,
Hi Tieftoener,
Yes of course I am using my own clock in the transport. In fact I still have the CS8412 in my DAC and normally I use the afore mentioned switch to choose between CD sound (I2S direct) and digital satellite tuner sound (SPDIF). It could also done with two 74HC125.
;)
 
Re: Re: Re: Schmitt triggers stink because......

Elso Kwak said:

Hi Terry,
Any schematic?
Or is it just a one transistor emittor follower? Is it at the DAC(receivers end) or at the CD players end?
Thanks in advance.
Interestingly when I did a search for cable drivers and receivers I found the receivers seem all to use Schmitt triggers!
Elso/only using SPDIF for satellite receiver

WRT DA12, the circuit was application specific. From memory there
was a +-12V supply to use at dig IP board, so it was easy to
bias a follower with simple R down to -supply. There was some
level shifting required though which I did with a diode to get
right DC level into receiver chip.
However, you get the picture, class A discrete high speed circuitry
works very well to buffer the receiver chip. Use your imagination,
I can think of quite a few ways to do it.

Cheers,

Terry
 
Re: Clock Transport

Elso Kwak said:


Hi Tieftoener,
Basically I am using a NON-OS DAC. This implicates I don't need the masterclock in the DAC. So why sending it from the DAC to the transport? And this is DIY. Three cables, or four with deemp, don't bother me. I want the ultimate in sound quality.
In my player DAC combination I omit a lot of chips and a PLL using I2S direct. Guido is doing a great job constructing a FIFO. This is way over my head. I can only think out simple schematics...
With the flip of a switch I can compare SPDIF with I2S direct. The switch is located as a two way for the I2S signals just prior to entering the DAC (TDA1543). In all honesty the CS8412 is not bad but you loose some quality. But I had to implement a lot of stuf for the CS8412: DIR with resetcircuit, AD8561, digital +/-5V supply, low noise +5V analog supply (for PLL).
:bawling:

About the fifo, if you remove all the logic to split i2s into left/right and making the signal differential, there is not much left.
I copied the input side of the fifo, just the output side is changed.
The FF is to start the read only when the fifo is half full. The 11.something MHz clock is connected to a divider and should go to a 7210/7310. The or gate there is for buffering.

Just an example, i did not build this! logic types are just what i found quickest so use your favourite instead of hc(t).

The output is NOT i2s, since the fifo goes to high impedance when read is high. The data and ws line go high then because of the resistors. Read is done on the high to low flank of clock/div4.
Read in a tda1541/1543 dac is done on low to high. So at that moment data and ws are ok. According to the datasheet, the inputs need to be 0ns (1541) and 2ns (1543) stable after bck going high. The fifo goes to high impedance 5 ns after read going low to high. So that should be ok.

If you want real i2s, use some ff's clocking low to high and invert the bck. Timing: bck = 2.8 MHz = 354 ns. Data needs to be ready at the dac 32 ns before bck goes low to high so the slowest (cheapest) fifo (65ns setup) should do.

Just to show you an idea.

GuidoB
 

Attachments

  • schematic _ fifo.zip
    16.7 KB · Views: 448
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.