I2S interface

[ted_b]

I like SIngxer's approach, which is to be as compatible and flexible as possible with the I2S "standards" (as we used to say in the software world, "ah standards, and so many to choose from"). It's a different perspective, but I think the DDC or source ought to be the one getting in line. The SU-1 has 8 dip switches for the I2S interface, easily accessible on the bottom panel. Switch 3 and 6 ON, for example, and you have the Gustard setup. It goes beyond just LVDS polarity (but that can be done by switching number 3 on).

[plissken]

It uses an IC to translate back and forth from 3V LVTTL levels (single-ended) to differential Bus LVDS (BLVDS) output levels.

 

Can this be considered native? Or is it a conversion like any other interface like USB, TOSLink, AES/EBU etc?

[vortecjr]

Can this be considered native? Or is it a conversion like any other interface like USB, TOSLink, AES/EBU etc?

 

I would consider it native. At the end of the day it's all a conversion because the content is stored as 1s and 0s on spinning drives.

[plissken]

I would consider it native. At the end of the day it's all a conversion because the content is stored as 1s and 0s on spinning drives.

 

My thinking was along the lines of RS232 to RS485 isn't a huge leap in conversion.

 

But RS232 over TCP/IP is.

[JohnSwenson]

My thinking was along the lines of RS232 to RS485 isn't a huge leap in conversion.

 

But RS232 over TCP/IP is.

 

There is no data conversion, the single ended TTL level signals are converted to differential low voltage signals, that is it.

 

So very similar to RS232 to RS485.

 

John S.

[JohnSwenson]

My thinking was along the lines of RS232 to RS485 isn't a huge leap in conversion.

 

But RS232 over TCP/IP is.

 

There is no data conversion, the single ended TTL level signals are converted to differential low voltage signals, that is it.

 

So very similar to RS232 to RS485.

 

John S.

[One and a half]

There is no data conversion, the single ended TTL level signals are converted to differential low voltage signals, that is it.

 

So very similar to RS232 to RS485.

 

John S.

 

Is it difficult to encrypt this data?

[The Computer Audiophile]

... I'm not interested on usb or s/pdif solutions, no matter how good, I want to use the native format of the DAC (I2S)

 

Hi George - I'm interested to learn why you are only interested in i2s or in your words, the native format of the DAC?

 

I think if we flesh this out, other people can learn more about this specific aspect.

 

Thanks George.

[17629v2]

What I'm asking is it an actual standard recognized by an official body like the IEEE or ISO?

 

There's no standard.

[BobSherman]

I'm not against this for a simple system. However, it's not likely going to replace a Holo Spring Level 3 DAC. You might also want to ready this about the issues with the i2s output on the Pi:

 

The Raspberry Pi: Audio out through I2S | Dimdim's Blog

Thanks for the information and trying to steer the thread on topic. Of course the OP would not be interested in such a solution. One thing with that little blog though it is sort of half correct. The I2s from the RPI is not up to par, but with a hat that can re-clock it and then output a better signal it can be usable. The hi-fi Berry can be used to output proper I2s. There is also some very good stuff on DIY design by Ian from Canada. This is not really what the OP is interested in but just wanted to provide a bit of helpful information.

 

Regards

Bob

[JohnSwenson]

Is it difficult to encrypt this data?

Why would you want to encrypt it? That just adds processing which is something you want to avoid.

 

John S.

[One and a half]

Why would you want to encrypt it? That just adds processing which is something you want to avoid.

 

John S.

 

If the data contained streamed dsd...

[bibo01]

If the data contained streamed dsd...

 

...then you don't even need I2S. For DSD you don't need MCLK at all, only bit clock.

You can have 24.576 MHz for 48k x 512. Only DoP uses I2S.

 

Jesus explains it here:

http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/direct-stream-digital-only-using-dsc-1-2-or-3-a-24310/index3.html#post423386

[One and a half]

...then you don't even need I2S. For DSD you don't need MCLK at all, only bit clock.

You can have 24.576 MHz for 48k x 512. Only DoP uses I2S.

 

Jesus explains it here:

http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/direct-stream-digital-only-using-dsc-1-2-or-3-a-24310/index3.html#post423386

 

Sorry didn't make myself clear, this is streamed dsd straight from the spinning sacd.

[bibo01]

Sorry didn't make myself clear, this is streamed dsd straight from the spinning sacd.

 

Are you talking about ST Fiber DSD (Emm Labs, Playback Designs)?

[One and a half]

Are you talking about ST Fiber DSD (Emm Labs, Playback Designs)?

 

No, accuphase and perhaps psaudio.

[davide256]

For example these 2 are cheap and very well received by audiophiles

Breeze Audio DU-U8 XMOS USB to SPDIF converter with Talema transformer and TCXOs

Gustard U12 USB Interface 8 Core XMOS chip

 

I have a Gustard U12... the iFi Nano DSD performs better in my system as an asynch USB converter, less veiling and distortion of bass

[bogi]

I have a Gustard U12... the iFi Nano DSD performs better in my system as an asynch USB converter, less veiling and distortion of bass

 

Thanks, but debate is about I2S capable converters.

[JohnSwenson]

If the data contained streamed dsd...

 

A couple of implementations use the I2S wires to send DSD data, the SDATA wire is one of the DSD channels and the LRCLK wire is the other DSD channel with the BCLK the same. Unfortunately it is not standardized at all, I have seen implementations that swap the channels (one puts left channel on SDATA and the other puts right channel on SDATA.

 

A problem with this is that you need some sort of external mechanism to tell the receiver whether it is DSD or PCM data.

 

John S.

[Blueline]

https://docs.google.com/spreadsheets/d/1h5PMUBkldkpt1rCnAR4ZHYGZNeCe-vwIFyKWYMZWsX0/edit#gid=853411704

[JohnSwenson]

Some info on I2S and especially I2S between boxes.

 

I2S is very simple, no packets or overhead, one wire with serial data, alternating between left and right channels on the same wire, an LRCLK signal that says when it is right data and when it is left data and a bit clock, that specifies when to read the serial data line. In addition sometimes a "master clock" is sent along as well, this is an integer multiple of the bit clock.

 

The timing of the signal is on these wires. If the DAC chip is connected directly to the wires, there is no other timing, so whatever is generating the I2S signal IS determining the timing and jitter going into the DAC chip. Thus if the I2S signal is coming from another box/board, THAT is now directly determining the jitter going into the DAC chip. How the I2S signal gets between the boxes has a lot to do with how good that timing is really going to be.

 

It IS possible to use a local clock that will reclock the incoming I2S signals, but in order for this to work that local clock has to be sent to the source of the I2S signals so it can synchronize the signals to the local clock in the DAC. This requires a DAC that sends the local clock OUT and a source the synchronizes itself to the local clock. These are few and far between, and the few that do, do not always use the same clock signal or pins on the interface cable.

 

So lets take the more common case of an I2S source and DAC that do not synchronize to each other, the clock in the SOURCE is in charge. If the source has a REALLY good clock and the circuitry used to drive the link between boxes is REALLY low jitter, then this configuration MAY sound better than another interface using a local clock in the DAC. If the DAC does not have a particularly good clock AND the I2S source component DOES have a really good clock, then the I2S connection may sound significantly better. If the I2S source does NOT have a really good clock then the I2S connection is probably not going to be much better and may be worse.

 

Another aspect to this is that all of the box to box I2S implementations out there do NOT block leakage loops between the source power supply and the DAC power supply. IF a setup is using the approach where a clock is fed back from the DAC to the source it is possible to implement isolation on the I2S signals, but I don't know of anyone that has actually done that.

 

Now on to the details of different I2S implementations. Most I2S signaling is done as CMOS level digital signals on PC boards between chips. This type of signal is only good for a few inches on a PC board. ANYTHING else, especially between boxes needs something different.

 

The early implementations used a single ended line driver chip to drive 75ohm coax, the most popular implementation used a DIN connector, the same one use by the S_Video standard. There were several companies that used this.

 

Recently most implementations have shifted to a differential method (LVDS - Low Voltage Differential Signaling) sent over HDMI cables, primarily because they already exist and the cables have just the right number of wires to make this work. This LVDS over HDMI gives significantly better signal integrity than the earlier single ended implementation over S-Video connectors. Unfortunately not all CMOS <-> LVDS converters are really low jitter, so there can be higher jitter levels in the DAC than there should be.

 

With a well done LVDS interface on both the source and DAC the jitter in the DAC is going to be primarily determined by the source, if it does a good job, the jitter at the DAC chip will be good, if it does NOT do such a good job, then the jitter at the DAC chip will be higher.

 

So as with just about anything else in audio there are no absolutes here, it depends on the implementation in the DAC and in the I2S source component.

 

John S.

[tboooe]

Very informative post @JohnSwenson! Curious what your thoughts are on the I2S implementation of the Singxer SU-1:

 

SU-1 XMOS USB Audio Bridge - 广州声仕电å*æœ‰é™å…¬å¸

[firedog]

I2S is a short haul interface meant for use on PCB's. You'll have to feed it with a long haul interface like S/PDif, TOSLink, USB, AES/EBU etc...

 

You are missing the fundamentals of how the I2S interface is meant to be used.

 

Misleading. I2S has for several years now been successfully implemented over HDMI. The Singer supports this.

The "fact" that the I2S interface was "meant" to be used as you describe doesn't mean much.

 

To GeorgeFlush: If you want to go for it, the Singer seems like a good solution. First reports about it are positive. TedB has some experience with I2S, and he seemed to think the Holo/Singer I2S solution was a superior one.

There are a few other converter boxes on the market that output I2S - can't remember them all, but I think Rockna/Hydra makes one, and there are a couple of others.

[One and a half]

https://docs.google.com/spreadsheets/d/1h5PMUBkldkpt1rCnAR4ZHYGZNeCe-vwIFyKWYMZWsX0/edit#gid=853411704

 

The spreadsheet is awesome however the implementation is a 52 pickup...

[franz159]

Thanks for the information and trying to steer the thread on topic. Of course the OP would not be interested in such a solution. One thing with that little blog though it is sort of half correct. The I2s from the RPI is not up to par, but with a hat that can re-clock it and then output a better signal it can be usable. The hi-fi Berry can be used to output proper I2s. There is also some very good stuff on DIY design by Ian from Canada. This is not really what the OP is interested in but just wanted to provide a bit of helpful information.

 

Regards

Bob

 

And what would be the helpful added information compared to vortecjr post? The existence of "DIY design by Ian from Canada"? I think a link could help a lot! Thanks