AES to I2S converter . How?

[Moby]

Well, that's the question  ;D

 

[jdbakker]

Functionally any S/PDIF receiver will do. Jitter-wise some more work is required.

JDB.
[there are only a few minor differences between AES and S/PDIF bitstreams, and the electrical end isn't too hard either]

 

[Moby]

Thanks, yes I know that spdif to AES is not a problem but can you suggest some low jitter app for conversion to I2S?

 

[Rochey]

DIR9001 with a RS485 reciever on the front end.

DIR9001 only accepts a CMOS level S/PDIF signal (such as the type you get from an optical reciever)

AES/EBU is electrically similar/identical (i'm sure someone will point out a difference) to RS485.

Anyway, an RS485 interface IC should give you a 5V or 3.3V output. The DIR9001 should be able to handle a 5V input if it has to.

Good luck.

/R

 

[jdbakker]

Thanks, yes I know that spdif to AES is not a problem but can you suggest some low jitter app for conversion to I2S?

Like I said, any S/PDIF receiver.

This includes the DIR9001 that Rochey mentioned, and the TI DIX4192, and the receiver portion of the SRC43x2, and the Cirrus CS841x series, and many other chips from Wolfson AKM and the like. Not all of these will directly interface with AES levels, but there are several simple solutions to that including the 485 receiver Rochey mentioned.

All of these have an on-chip PLL, limiting them to 100ps jitter at best. If you need better clock recovery than this, you need either a low phase noise secondary PLL or an FPGA-based SPDIF/AES receiver with an optimized PLL. I know of no off-the-shelf solutions for this part.

JD "and if you have to ask, you can't afford it" B.

 

[Rochey]

JD,

Let me put my marketing hat on for a moment

The dir9001 achieves 50pS of jitter from it's PLL.

*beams with pride*

However, I would suggest that having the lowest jitter isn't an absolute critical thing. Bear in mind that most ADAT implentations have 1nS of jitter...

 

[Moby]

Thanks guys, yes 50ps is quite good for me  ;D BTW, it looks that this nice guy already did the homework for me. What do you think about it?
http://pavouk.org/hw/modulardac/en_dir9001spdif.html

 

[jdbakker]

The dir9001 achieves 50pS of jitter from it's PLL.

That's not too shabby, and probably directly usable in several situations, but it's still within the same order of magnitude. If you want to get the best out of a 120+dB dynamic range converter, you'd need less than 5ps jitter at your converter clock.

However, I would suggest that having the lowest jitter isn't an absolute critical thing. Bear in mind that most ADAT implentations have 1nS of jitter...

...and nobody in their right mind, not even Behringer, uses that to directly drive a converter chip's master clock. I've never seen a commercial design where the clock output of those chips wasn't driven into a secondary PLL (and you know you have way too much jitter when even a 4046 with an LC VCO can clean up your clock).

JDB.
[pet peeve, but you knew that]

 

[Moby]

nobody in their right mind, not even Behringer, uses that to directly drive a converter chip's master clock. I've never seen a commercial design where the clock output of those chips wasn't driven into a secondary PLL (and you know you have way too much jitter when even a 4046 with an LC VCO can clean up your clock).

Clear, but I plan to serve already built DAC board with II2 signal and board where the digital audio stream is upsampled to 24-bit 96KHz by an asynchronous sample rate converter (ASRC) and then converted to analog with Wolfson's top-of-the-line ΔΣ oversampling DAC chip.  An onboard ultra-low jitter oscillator provides the master clock for the ASRC and DAC chips.
Can I expect the 50ps under the DIR9001 to be improved with ASRC oscillator quality?

 

[jdbakker]

Can I expect the 50ps under the DIR9001 to be improved with ASRC oscillator quality?

Yes, but...

Any ASRC has a rate estimator; this rate estimator functions as the secondary PLL I mentioned earlier. While this will reduce jitter, some of the jitter will be irreversibly transfered to the signal. So while an ASRC plus a good low-jitter clock can work well, it's no panacea for interface jitter. If at all possible, try to pick a frequency for your DAC clock which is not (close to) a multiple of your AES sample clock. This will reduce jitter transfer; see Bruno Putzeys' AES Masterclass slides for more.

JDB.
[and before Rochey mentions it: if I were starting a new design with such an architecture, I would take a long hard look at the TI SRC4392, which has an AES/SPDIF receiver(/transmitter) and a pretty good ASRC, with I2S I/O]