I2S standards from PS Audio

[paulmc]

Hi everyone. As many of you probably know, PS Audio is one of the manufacturers out there supporting I2S digital output/input format as a better alternative to S/PDIF.

The I2S format has separate clocks and data and lower jitter and better performance if handled properly. I2S is the native format inside every CD player. If you are using a separate transport, the native I2S inside the transport must be converted into S/PDIF format to get out and into your DAC. This is not the best way to do this.

When we released the PerfectWave DAC and Transport a year ago, we decided to include I2S as a standard interface between the two machines. We also decided that the best way to transfer the I2S data was over an HDMI cable. There are many great HDMI cables available on the market and it's an excellent interface cable.

Our engineering department spent a great deal of time developing a "standard" that works quite well and several other companies have already adopted this standard. Our hope is that more and more manufacturers will include a similar interface on their devices.

I figured the DIY guys would be the logical choice to get this ball rolling so I have attached the schematic for the interface. You are free to use this in any way you see fit. I would appreciate a bit of publicity on this, but nothing more.

If you have questions, direct them to me paul@psaudio.com and I'll do my best to pry someone out of engineering to help.

Good luck and have fun. Drop me a note if you do this. The results are noticeably better than running through S/PDIF or AES/EBU.

Paul

[jstang]

Nice of you guys to share....!

jk

[paulmc]

Our pleasure. Always happy to share.

[rossl]

how is the I2C bus used in the link?

[SoNic_real_one]

That's nice, but it wold be more usefull if it had capability for surround sound too.
IMO the clocks should be combined in just one, there is no need to dedicate 3 separate differential channels for that. Other than simplify the schematics that is...

I would use the 'Clock' pair for general clock and the 'Data' pairs for the 3 audio data necessary for 5.1 surround.

[rossl]

The I2S bus needs all four of those signal pairs. The MCLK is 256X the sample rate, The LRCLK tells you left or right channel 1X sample rate, and the bit clock is 64X the sample rate.

That one could possibly be derived from the MCLK. So, you would still need a minimum of three.

It would be better to add another HDMI cable for multichannel.

[SoNic_real_one]

You need just the bit clock, the rest can be derived (XTAL clocks, triggered by BCLK in the other end for MCLK), eventually with some encoding for the LRCLK in the stream...
There are only 4 pairs in a HDMI or in a CAT5E cable. If some could work around the three clock issues... that would be awesome.
But not on the RIAA "guidelines" I guess.

[rossl]

Originally Posted by SoNic_real_one

... that would be awesome.
But not on the RIAA "guidelines" I guess.

now you're designing a new interface that's not I2S format



if each sample has 24 bits of data, then you do have 8 trailing bits available in each word that could identify the channel. and a few other parameters.

[SoNic_real_one]

No, I was thinking in leaving the data untouched, but encoding differently the clock.

Something easy to do at DYI level like voltage level shifting for L/R channels. After all is a low freq clock.
MCLK I guess is easy to accurate regenerate from bit clock? PLL maybe?
Hmmm, sorry, didn't want to hijack this thread. I'll think about it in a month, now I take some exams

[paulmc]

I'd be careful of this approach. PLL's introduce jitter and are not desirable if you can avoid it. What we have shown here works extremely well.