I2S: Is it a good external interconnect? Give your opinion and findings!

[Mr.C]

It seems like we need a thread to clear up this topic because if it is the best option then it needs to be said. If it is an inappropriate option then it needs to be discarded.

 

This continues on comments from the "best" interface thread and things from other forums. There seem to be two opinions: it is only good for internal, very short connections (Gordon Rankin and Dan Lavry I think); It is THE BEST, or at the very least a very good option worthy of considering, external interconnect format (Steve Nugent, other dac manufacturers like PS Audio, Northstar, Audio Alchemy, April Music).

 

Evidence for it working very well is first from the HiFiNews review of the Perfect Wave Dac where I2S was the preferred connection among AES, S/PDIF, and usb. Other reviews like the positive feedback reviews of Steve Nugents products also point to it being the best option.

 

Evidence against it is the general lack of using it outside internal boards and explicit comments by some manufacturers against it.

 

Anyone else?

 

[The Computer Audiophile]

I believe the HiFiNews review of the PS Audio units was released before PS Audio even released the final version of its code for the PWD and PWT. Based on the PS newsletter the they just finished it and started shipping. I don't think HiFiNews could have received a final version of the product before it was finished. Take it for what it's worth, but I'm not sure an opinion of interfaces should be taken very seriously on a preproduction unit.

 

Just a thought.

 

[idiot_savant]

how the output from (say) a CD-Pro2 is I2S, and the input to most DACs is I2S, and yet nearly all manufacturers go to the trouble and expense of adding SDPIF encoders and decoders?

 

For a $43,000 implementation of I2S:

http://stereophile.com/cdplayers/1106zanden/index4.html

 

which is admittedly better than it's AES implementation ( which is awful ).

 

ALTHOUGH it gets a good listening write-up, so who knows?

 

Why doesn't anybody use SDIF-2 any more?

 

your friendly neighbourhood idiot

 

 

 

[Mr.C]

Chris, I think the response to this at the PS Audio (?) boards was that the preproduction units had finalized hardware and that they were just working out software bugs (unrelated to performance).

 

[cfmsp]

"Why doesn't anybody use SDIF-2 any more?"

 

EDIT: I didn't notice that "SDIF-2" was NOT S/PDIF until after posting the words below. SDIF-2 is, I think, a version of S/PDIF (or AES/EBU) without the clock being multiplexed into the signal.

Apologies for my carelessness, IS.

 

 

Some folks in the recording forums (users & proponents of Firewire) believe that S/PDIF's only place ought to be for 'legacy' audio, i.e. CD Transports.

 

Given S/PDIF's embedding of the 'clock' with the data signal, they may have a point. Certainly Firewire and Async USB would seem to have a theoretical advantage, which may be outweighed now by the many year head start that the audiophile DAC manufacturers have had focusing on S/PDIF.

 

I2S, at least, separates the clock signal from the data signal, while still transmitting both, and allows for optional generation of Master clock signal from the receiving device (as opposed to the transmitting device). Presumably the option would be 'mandatory' for implementation of i2s from computer to DAC.

 

I'm certainly no expert, but why would you want to use an electrical serial bus interface (designed for communication between IC/chips on circuit boards) instead of protocols designed specifically for data transmission?

 

If the primary goal is to move data to the DAC SANS any sort of interference from the computer and/or the surrounding environment, why convert the data signal any sooner than you have to? Said another way, what possible advantage could there be for creating a new type of soundcard to convert to i2s at the computer?

 

As I said, I'm no expert. I'm just asking?

 

 

 

 

[cfmsp]

 

DavidL posted this a couple of weeks ago:

 

"PWT / PWD combination review in August Hi-Fi News

 

Very favourable remarks by Keith Howard.

He thought I2S gives best sound on CD followed by AES/EBU, RCA SPDIF and USB a poor last. He preferred the 'native' mode on CD i.e. no upsampling. On hi-res material the sound quality did not really advance on that from an RME Fireface 800 connected by firewire to a new Mac mini: in some cases the latter was better."

 

http://www.computeraudiophile.com/content/PS-Audio-PWD-Perfect-Wave-DAC#new

 

Apparently, I2S couldn't best a pro audio Firewire interface.

 

 

 

 

[Audio_ELF]

Using the example of the connection between the Perfect Wave Transport and Perfect Wave DAC is a little erroneous as IIRC, PS Audio have stated that the connection isn't just "standard" i2s and that it is incompatible with any other implementation of i2s - implying (to me anyway) they've done more than just extend the IC tracks external to the box.

 

Comments explicitly against i2s (that I've read) have come from Gordon (on this forums several times) and dCS (on their website FAQ). Implicitly most other companies don't support using it as I'm sure people like Cyrus and Wadia and Chord (all who have separate transports and DACs in their range) who don't use it. As commented, considering the number of people who make DACs, very few are proponents of the i2s interface - I'm sure that someone has spent time evaluating it in most audio companies.

 

@clay

If I understand correctly, SDIF is SONY Digital Interface and has been through various incarnations and is now up to SDIF-3. SDIF-2 and SDIF-3 can also be used for the transmission of DSD data. There are a few devices supporting such interfaces - dCS Scarlatti SDIF-2 DSD and Tascam DSD recorders have SDIF-3 connections.

 

Clay later said... "Apparently, I2S couldn't best a pro audio Firewire interface." of course would be interesting to see what a i2s interface from a computer can do ... maybe. A possible (logical) explanation about the results with the PS PWT and PWD is that with 44.1khz of data/clock, the tolerances are greater than with 192k data/clock which could explain why at CD quality the i2s connection was best, but with High Resolution the AES connection was better.

 

I think in summary there are some good implementations of i2s, however that doesn't make it a better interface than SPDIF. I've read that with i2s, because the clock is separate from the data, the data and clock signals can become dis-synchronized (not sure thats a real word) from each other - jitter still measures well, but the sound will be awful! The individual cables in the connecting cable need to be exactly parallel and exactly the same length - and thats just not possible.

 

Eloise

 

[cfmsp]

 

"of course would be interesting to see what a i2s interface from a computer can do ... maybe."

 

I left off the 'smiley' that should have followed my comment about i2s not besting firewire.

 

as for a computer interface, I don't see that happening necessarily. I see i2s being implemented in an attempt to beat back the onslaught of computer audio, IOW, a way for audiophile manufacturers to continue selling transports along with their DACs, by using a semi-proprietary interface.

 

For computers, you'd need a soundcard with i2s output (unless you construct your own computer) and you'd probably want to have a specific target device (i.e. DAC) in mind as little niceties like 'cable termination' type are apparently missing from the I2S spec (as it was likely never intended to migrate from the circuit board). i did read that ethernet would probably work well. PS Audio chose HDMI, another logical choice I guess.

 

[Tog]

I seem to remember a number of late 90s Dacs that had IS2 connections and the blurb seemed to indicate that this was a fabilous way of doing things - Scott Nixon's tube Dacs had internal IS2 gubbins ( tech too much for a small bear) but I didn't like the sound. The Cyrus approach of high perfoming (dare I say it jitter resiliant) dula mono dac design and separate transport works a treat - although I have replaced my transport with a Macbook Pro.

 

yours, tog

 

[PeterSt]

I use I2S from the PC (and a tweaked soundcard) and I really don't see the problem. More jitter than with SPDIF ? I don't think so (but, I can't measure it, or anyway didn't take the indirect route of doing it yet). But I can tell you, it sounds better.

 

Of course this is logic when the DAC (chips) take I2S for input, while SPDIF has to be converted to I2S first, but keep in mind that it might come down to just these things. I mean, a DAC chip taking SPDIF directly (as the only connection) needs it the other way around.

 

My (CAT5) cable is near 1m (say, 3') and I didn't even terminate it because the clock line looked very good on the scope to begin with.

Is it more sensitive ? I don't think so. Or anyway I use it with 48 sample latency at 24/192 (wrong, that would be 32/192 physically). Now, try that with SPDIF.

 

I2S gives the sound a "sweet" character, and after hearing it, SPDIF is rough-like. Anyway in my case it is.

 

Peter

 

[idiot_savant]

I've suddenly realised that what seems obvious to me isn't obvious to everyone else, so how's about a quick overview of digital audio interfaces?

 

No?

 

well, I'm going to start anyway....

 

WHY do we need something that isn't I2S? As I mentioned previously, this is a standard that was designed, and is still in use for transferring audio between ICs ( I2S stands for inter-IC sound ). It consists of three wires:

A "frame" which represents a frame for a sample - the idea is, if it goes high-to-low, that is the start of a LEFT sample, and low-to-high is the start of a RIGHT sample. This effectively is a square wave at the sample rate ( so, for CD data runs at 44.1kHz )

Next we have a thing called a "bitclock". Depending on the implementation, there may be 16, 24 or 32 clocks per half-frame. This signal is used to indicate the changes in data, so when this signal goes from low-to-high, there is another bit to do something with

Now we have the data. This is streamed serially, first the left sample, then the right sample.

So, for a DAC to read a set of stereo samples, it waits for the frame to change. It then knows which channel the audio it is receiving corresponds to, and when that data is being shifted.

So, in a common example, we are feeding CD data to a DAC, these wires will have the following characteristics:

The frame will be a square wave, at 44.1kHz, where it being low indicates "left", and high indicates "right". The bitclock for some implementations runs at 32x44.1kHz - 1.4112MHz ( 16 bits/sample, 2 channels, 44.1k rate ), others at 48x44.1kHz-21.16MHz ( 24 bits/sample, 2 channels, 44.1k rate ), some at 64x44.1kHz - 2.882MHz ( 32 bits/sample, 2 channels, 44.1k rate ). The audio will be serially streamed, and padded with the appropriate number of zeros for the frame width.

Now, this all sounds pretty cool, right? The things that clock and frame the data are on different wires, and therefore can't cause the receiver to have jitter?

Unfortunately, this is wrong BECAUSE the spec only specifies a maximum of something like 6" between components, with no real termination requirements.

So, you're transmitting an edge-critical signal over a few feet without specifying the termination between those components, and at least two of these signals are in the MHz range. Reflections and unpredictable rise times are guaranteed to be awful in this kind of scenario, and in addition, because the bitclock and data signals are extremely tightly coupled ( and quite high speed ), you also have to worry about skew between the three wires ( for instance, 10uS of skew means that you're interpreting the wrong data in a sample ). These problems will get worse as the sample rate goes up...

If anyone cares, I'll write a few words about SPDIF/AES and why it was invented tomorrow, and why it will always be better than I2S ( from a technical standpoint, at least ) between boxes

 

your friendly neighbourhood idiot

 

PS I really can't remember, and it doesn't matter for this discussion the absolute polarity of these things...

 

PPS SPDIF/I2S latency? Peter, please..........

 

[The Computer Audiophile]

Very interesting. I like all the detail.

 

[vortecjr]

Peter, is your dac tweaked as well or was it a stock unit with the i2s input?

 

Idiot_savant...your no idiot! Please continue!

 

Lately, I have to tell you I am liking the idea more and more of the dac being in the source! I can really appreciate now the Ayre way and Gordons design as well. Just come out analog..."keep it simple stipid". Of course I am referring to me....hehehe.

 

 

 

[PeterSt]

Hey i_s, nice ... thanks.

 

PS I really can't remember, and it doesn't matter for this discussion the absolute polarity of these things...

 

PPS SPDIF/I2S latency? Peter, please..........

 

But I don't know what you want with this ? So maybe this does not make any sense :

 

First what I said :

 

Is it more sensitive ? I don't think so. Or anyway I use it with 48 sample latency at 24/192 (wrong, that would be 32/192 physically). Now, try that with SPDIF.

 

Of course this by itself makes no sense because I responded to the earlier remark about the sensitivity, and should have stopped at mentioning 32/192. I mean, the protocol itself won't have to do much with the latency of things (yea yea if you include overhead bytes and the speed of electrons etc. blah blah it will). The point is, I am rather enthusiast about the achieved latency, because with SPDIF it can't be done because of the drivers or whatever all is in between. So, in the end it is just related to I2S, and not caused by its inherent properties.

 

May I ?

This *is* enormeously important, because it is generally accepted (by me haha) that the lowest latency gives the best sound. Allright, so with 16/44.1 (or 24/44.1) up to 24/48 this is 48 samples, and it is that because the drivers most often won't go lower (although I know of a soundcard using 32).

For 24/96 this is 96 on a safe side, but 64 can be done as well, though too critical to safely use.

 

The above means that when I want to compare 16/44.1 to 24/96 (or higher) material wise, this can't be done, because *or* I must judge 44.1 at 96 samples latency which is not the best, or I must compare apples with oranges, which I won't.

Side note : It must have happened a 50 times at least that because of testing (player) I left the latency at a high value, started listening in the evening (which I always do for several hours) and after 30 minutes or so started looking for what is wrong. And of course I again forgot to set back the latency. I only want to say, this really matters.

 

So as said, I got enthusiast at mentioning the latency in one go with the sample rate, because this is very important to me, and I2S just allows it.

 

Down to the real merits of things, we must be careful what latency means in this case;

Although the 48 samples actually tell that it's around 1ms, this is not how it can workout with audio playback, because there's always the (circular) buffer in the PC, or IOW the memory which is shared between the PC and the DAC (driver side of it). This buffer is larger than 1ms and the effect is that the actual latency may be even 700ms (this depends on the DAC). It will not mean that it takes 700ms before you hear sound after pressing Play, but it will mean that you still hear sound for 700ms after pressing Stop.

On a sidenote : although the buffer size is determined by the DAC, it's used size can be influenced by software.

Now, this 48 sample latency will be equal to a buffer (another one) in between the driver and the DAC (but correct me if I'm wrong please, because I actually don't know this), and the smaller this buffer the better "response" (at e.g. playing a MIDI keyboard which directly connects to the driver) but the more the overhead, and the larger this buffer the more sluggish things are (set it to 1000ms and your note plays after one second), but the less overhead.

I don't know which protocol carries what overhead, but if we figure that for 48 samples this may be 100% (like header data occupies 2 x 48 words), for 48000 2 channel samples it would be 1%%. Really a huge difference.

(of course this makes no sense without real figures, but I just don't know them, sorry).

 

Lastly, apart from overhead in the protocol, there's also the conversions. Thus, when SPDIF has to be converted to I2S inside the DAC, this takes time. This is minimal, but if you know this is all about small buffers, shift registers (that may turn around left and right words or bytes (a word is a functional group of bytes, like one sample for one channel takes 32 bits = 4 bytes and we call that one word), shovle out the "procotol data" and some more, it could take 1 ms I suppose. This is also the area where jitter emerges, and so when this all doesn't have to be done, you gain on several areas.

 

I better stop now.

Peter

 

[PeterSt]

Peter, is your dac tweaked as well or was it a stock unit with the i2s input?

 

Tweaked ? hahaha. You could say it is one big tweak. It was build from the ground by my functional specifications, sauced with the technical knowlegde on engineering by, well, the engineer who actually did it (and hey, it is four layer, to name something).

 

When I talked about the I2S clock line and the scope and all, I must honestly say this *was* true, but not anymore. The DAC I have now, is another one than the one from 3 weeks or so ago, and this one uses I2S but two lines only ... (here I'll stop, sorry :-).

 

Anyway, indeed it is one big tweak, because at applying some "unofficial stuff" problems arise in quite some areas, like the FPGA (Field Programmable Gate Array) being too small to hold all the logic that automatically determines the sample rate and everything, and it really took some "fights" to avoid a manual switch for it.

This also incorporates stupid stuff like 16/96 (and 16/88.2) data to be treated like so, instead of padding to 24, which actually springs from XXHighEnd being able to do that which originated from allowing 24/96 data to play on 16/96 DACs. However, data just can be like that, and while it is, the DAC should run the most lean as possible.

So, while it could take seconds at locking onto the correct bit depth and sample rate, it now contains logic that quickly determines whether anything changed since the before lock, and if not, just shuts off the uP and continues with whatever it was before.

Well, I guess any DAC manufacturer has to deal with these kind of things, but I only wanted to indicate that is really has been built from the ground, and that at least I recognize the work Gordon has been done in the same kind of area.

And then I didn't talk about the I/V, actually being the most crucial part ...

 

Back to I2S ... to get that done well, really is the most hard part. So, my tweaked PCI card really isn't the final solution because that will be Firewire (and I2S from there on).

 

 

[Tog]

Yep you lost me after "When..."

Tremendously exciting stuff and yes it does remind me of when the hero in a scfi film turns to the boffin and at the climax of the action yells..."Reverse the polarity!" sounds great - no idea what it means......

 

Haven't you compensated for random latency on the OpAmp stages at all...go on just a little bit..... or are you worried that a loss of bit depth will hamper your sample rate?

 

I know I would be

 

Off to get my copy of Random Electronics Monthly ...

 

yours, totally polarised, tog

 

[Audio_ELF]

REVERSE THE POLARITY OF THE NEUTRON FLOW!!!!!!!

 

[idiot_savant]

OK, since there appear to be some people who like to know how this stuff works, we'll move onto the interface everyone loves to hate, SPDIF. NOTE AES and SPDIF are pretty much the same thing - typically, they're on different connectors, and the messaging subdata is different between them, but it's mostly irrelevant for this discussion, and where I say SPDIF, you can read AES if you want.

SPDIF runs over a single wire, with a set of fairly tightly defined electrical characteristic to allow it to travel fair distances with no real problem. So, if I2S needs 3 wires to send the data, how come SPDIF only needs one?

It works by again transmitting data as frames ( a pair of left right samples ). Each subframe is 32 bits long, and is split as follows:

bits 0..3 : are a preamble, which is one of 3 types, to indicate left,right,and block start, and are essential

bits 4..27 : is the audio ( it can actually be e.g. 20 bit audio with 4 bits ancilliary, but we'll ignore this )

bits 28..31 are known as the VUCP bits, which are Valid, User, Channel status and Parity

Now, these bits are encoded using a technique called differential manchester encoding - this is where, rather than a logic high being a 1, and a logic low being 0, a bit period is of a known length, and if there is a high-to-low or a low-to-high transition in this period, this is a 1, and if there isn't it is a 0. To add complications, there is ALWAYS a transition between bits. This helps us know if we are really looking at SPDIF or not, and is important because:

The only place where there can be no transition for longer than a bit period is in a preamble ( the thing that marks the start of a sample ). A preamble is GUARANTEED to have 1 and a half bit periods of no transitions.

So, to design an SPDIF decoder, we basically use something to work out where the longest period of no activity is, and assume that this is a preamble. Because you have a different preamble for left and right, our preamble detector output effectively turns into the same signal as the frame or wordclock from I2S. We also now know where transitions should be, and from that, decode the data ( effectively combining the bitclock and data lines from I2S ). Now this all sounds clever, eh? Combining those three wires and losing nothing into one wire?

Well, the problem is that the thing decoding it will naturally see some slopes on edges, or asymmetry in the waveform, which turn into jitter, combined with the fact that data with more '1's in it will have more transitions, you can see how it's actually quite difficult to decouple the clock from the data completely, and this is SPDIF's biggest weakness. So how can this be better than I2S, you ask?

Well, the answer is the use of a PLL circuit - these are typically integrated into SPDIF receivers, or ( much more rarely ) as discrete logic, or as separate ICs. The PLLs job is to reduce clock jitter - these work by effectively "averaging out" the the frequency of the frames from the receiver, and reconstitute a clock to feed to the DAC circuitry, which will have much less jitter than the raw clock decoded from the stream. They are most certainly not perfect, which is why I advocate using the DAC as the clock source, but they can be very effective.

So why can't you do this with I2S ( use a PLL )? Well, I've never seen a PLL in use with an I2S interface DAC/transport, and the reason is simple: The data and clocks in I2S are very closely linked together, and the PLL can only change the phase of one of these - so you use a PLL to smooth out the wordclock/frame signal, but the bitclock and data no longer are guaranteed to have the exact same phase relationship with it ( if they were, then the PLL cannot be working... ), hence lots of pops, bangs and crackles.

So, a typical transport->DAC scenario using SPDIF is:

transport out (I2S)->SPDIF encoder->SPDIF wire->DAC input->SPDIF decoder->reconstituted I2S->DAC itself.

 

there's really quite some detail you can go into here, but that's the gist of it,

 

Some companies go much further than others, e.g. completely separating the clock & data routes, to allow, for instance, data to come from SPDIF and clock to come from a wordclock. In these cases, a PLL is used to filter out jitter from the wordclock ( which can't have any data-dependency ), and the SPDIF only carries data ( which is self-clocking ).

 

your friendly neighbourhood idiot

 

 

[[email protected]]

here is a nice dac that doesn't cost that much that uses I2S

 

http://www.aprilmusic.com/main/sub02_02_03.html

 

they also sell a transport that has the I2s output as well.

 

just thought you might want to check it out.

 

[Wavelength]

Gang,

 

Do we have to go through this again....

 

I2S is internal protocol good for about 2cm... anything more and it will sound like crap. If you go between two different units don't expect this to work as good as say a $49 wal mart special cd player.

 

Thanks

Gordon

 

[vortecjr]

We are not pushing him though...its all him and he and other seem to like it!

 

[Tog]

I'm only a small bear but even I know that I2S doesn't stack up as an interconnect. I use the spawn of the devil s/pdif and one thing I have noticed is that even with really good equipment - redbook recordings have their limitations - which is fine because rather than listen to the electronics I prefer to listen to the music.

 

Get a good dac - I believe Gordon's might know where you could get your hands on one ... open a bottle of wine .. put on some music and give I2S amateur electronics a rest.

 

yours, small but furry ,tog

 

[Mr.C]

"Gang,

 

Do we have to go through this again....

 

I2S is internal protocol good for about 2cm... anything more and it will sound like crap. If you go between two different units don't expect this to work as good as say a $49 wal mart special cd player.

 

Thanks

Gordon"

 

I don't think we're going through this again, I think we're exploring it more indepth. The main question is "if this is only good for internal protocols, why are some audio companies using it for external communication with good reported results?"

 

[NiToNi]

http://www.soundstage.com/wrkman03.htm

 

http://www.soundstage.com/todd03.htm

 

[The Computer Audiophile]

Hi NiToNi - What did they know? I'm lost, please help :~)