Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Looking to get a good explanation of the I2S protocol used by DACs (Read 5592 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Looking to get a good explanation of the I2S protocol used by DACs

I really need an ELI5 explanation of how the I2S protocol is used by a DAC to get data from a USB cable to the DAC to playback as music.  I found the Wikipedia article, and it didn't give me enough detail (nor was it really dumbed down enough at this point in my learning), and the forum posts I found involved certain phrases that set of my placebophile detectors, with people discussion the superiority of TOSlink over USB because of I2S implementations, and that elusive buzzword jitter.

I searched the forum and the wiki for I2S and did not find anything.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #1 –
From https://en.wikipedia.org/wiki/I²S

The horse's mouth: https://web.archive.org/web/20070102004400/http://www.nxp.com/acrobat_download/various/I2SBUS.pdf

It's intended for very simple hardware and the spec is complete enough to implement I2S to match existing chips...

If you were asking how USB transfers audio, that's more involved, but you wouldn't be searching for I2S for that question.

I2S doesn't define a physical interface, but http://www.i2s.sonore.us has a chart wirings for of a good selection of DACs.


Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #2 –
The real question is, is there an audible difference between the USB and the optical interface on an external DAC?  Somehow I2S factors into all this and I'm trying to educate myself outside of our "audiophile" circles so I get the right answer.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #3 –
A USB to DAC interface may use I2S to get to a DAC, it can also be implemented with other things too, e.g. a single wire using the same protocol as TOSLink, S/PDIF, AES/EBU, etc. or something more direct.

So you may as well ask if 1) different connections, e.g. I2S, S/PDIF, AES/EBU, TOSLink make an audible difference and 2) if different connectors and wirings (e.g. twisted pair vs coax, ...) make an audible difference, 3) how a particular USB to DAC interface is implemented, etc.

The two most likely candidates for USB causing interference with the rest of the system are

1) ground loops caused by the various cables (and almost no-one does good controlled experiments when testing cables so much of the anecdotal data is very noisy - you need to only have the cable you are listening to in the system, i.e. take out the other cable if you really want to test if the ground loops are making a difference...)  And yes ground loops can matter, for example they can disturb the analog connections to the rest of your system...  and

2) jitter:  USB is particularly jitter inducing, both because the packets for 44.1k and it's multiples don't have the same number of samples packet to packet and because the power and ground are very close to the data lines in a USB cable.  Whether the resultant jitter matters depends on the rest of the system.  (And on the rules of the forum you discus this on :) )

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #4 –
I find it interesting that a lot of people talk about jitter in modern audio equipment, but I haven't found any examples of it posted online for someone to see hear an example of.  I just watched one YouTube video where someone claimed that if someone is tapping their feet to the music, that's a sign that jitter is minimized.

I find that to be complete hogwash.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #5 –
Quote from: apastuszak on
The real question is, is there an audible difference between the USB and the optical interface on an external DAC?  Somehow I2S factors into all this and I'm trying to educate myself outside of our "audiophile" circles so I get the right answer.

I2s is a simple serial connection used to send pcm audio data. With respect to your question, i2c doesn't factor into this discussion. It only matters if you're designing the board that a DAC runs on, which you are not.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #6 –
Please go to https://hydrogenaud.io/index.php/topic,107570.msg941578.html#msg941578  for some quick audio samples of piano with various amounts of 10 Hz jitter added.

There is a picture of a J-Test FFT for the "medium" file. The other files differ in steps of 20 dB. So this file shows the carrier at about -2 dB, and the highest sideband at about -30 dB down. The file with the next weakest jitter called "low" would have a similar sideband about 50 dB down.  The one with the weakest non-zero jitter is the "very, very low" file in which the jitter is about 90 dB down. The "reference" file has no added jitter.

The added jitter had a nominal repetition rate of about 10 Hz, and the jitter waveform is approximately triangular, which explains the complex sideband structure.

The source of the piano notes is file 39 of the SQAM files.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #7 –
Quote from: apastuszak on
The real question is, is there an audible difference between the USB and the optical interface on an external DAC?  Somehow I2S factors into all this and I'm trying to educate myself outside of our "audiophile" circles so I get the right answer.

The quick answer is no if we are talking different inputs on the same DAC. This assumes the jitter is the same on all inputs, which is not always true for random reasons. Good DACs remove jitter from the audio and clock signals that they may receive.


The explanation of I2S you have received is correct as far as it goes. There has been some effort to use I2S as an external signal connection, but it is usually for internal use only.

I believe that if you listen to the Jitter samples I posted, you will hear jitter become fainter and fainter as the jitter gets smaller. You should be able to use FOOBAR2000's ABX plug in to compare the various files with jitter added to the reference file. I would expect that you will run out of jitter to hear before you run out of test files. If you compare the supplied FFT to such test report J-Test FFTs as you may find, they will pretty much universally show less jitter then you'd see with this FFT adjusted for the lower levels in the other tests. IOW it would be hard to find a DAC that has jitter that is greater than what would be in the test file with the lowest amount of jitter as you can hear. (Unless I screwed up the test files!)

BTW, the choice of 10 Hz approximately equates to the FM distortion created by tone arm geometry and warp wow  for the common tone arm resonance frequency of about 10 Hz.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #8 –
Quote
Somehow I2S factors into all this
No...  Look...  It's just digital data (ones & zeros) and digital data is super reliable!  
 
Your bank account doesn't get corrupted...    I can send you an audio or video file over the internet and across the globe through who-knows what kind of complicated wired/wireless/optical connections and "formats" and it will arrive bit-perfect and you can play it perfectly.

Another example I sometimes use is this:  If there's a typo in this post, you can be pretty sure it was me, and not due to digital corruption.

Yes, stuff can go wrong, especially with real-time transmission...  Sometimes you get a bad cell phone connection...    But, there's no reason for anything to "go wrong" inside a DAC unless the DAC is broken or poorly designed.    And when things "go wrong" with digital, they usually go horribly and obviously wrong.    Again, think about that bad cell phone connection or a "glitch" in DVD playback or with broadcast TV...    You don't get slightly-lower resolution, you get a big-nasty glitch, or it just flat-stops working.    One wrong bit in your bank account can make a billion dollar error just as easily as a 1-cent error, but it just doesn't happen.   

Unless you are building the DAC, don't worry about what's inside!   Don't worry about what chips are used or anything like that...  What matters to the user is the specs/performance.   In engineering jargon, it's a "black box".    Digital goes-in and analog-comes-out and we don't care how  it's done.    

It doesn't matter if the bridge is made of concrete, steel, or aluminum...  What matters is that it holds-up when you drive across it, and maybe how it looks.  It doesn't matter if your amplifier is made with MOSFETs or regular 'ol transistors or if it has discrete components or integrated circuits (we won't talk about tubes).  What really matters is the power, noise, distortion, frequency response, and features.   Of course, the manufacturer is going to tout any engineering decisions/trade-offs as a feature, Discrete Bipolar Class A/B Output", or "MOSFET Power!"... or whatever....

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #9 –
Quote from: Arnold B. Krueger on
Please go to https://hydrogenaud.io/index.php/topic,107570.msg941578.html#msg941578  for some quick audio samples of piano with various amounts of 10 Hz jitter added.

There is a picture of a J-Test FFT for the "medium" file. The other files differ in steps of 20 dB. So this file shows the carrier at about -2 dB, and the highest sideband at about -30 dB down. The file with the next weakest jitter called "low" would have a similar sideband about 50 dB down.  The one with the weakest non-zero jitter is the "very, very low" file in which the jitter is about 90 dB down. The "reference" file has no added jitter.

The added jitter had a nominal repetition rate of about 10 Hz, and the jitter waveform is approximately triangular, which explains the complex sideband structure.

The source of the piano notes is file 39 of the SQAM files.

Thank you for the sample.  I've been trying to Google samples of jitter and not having a lot of luck.  I will play with these later today.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #10 –
Quote from: DVDdoug on
Quote
Somehow I2S factors into all this
No...  Look...  It's just digital data (ones & zeros) and digital data is super reliable!  
 
Your bank account doesn't get corrupted...    I can send you an audio or video file over the internet and across the globe through who-knows what kind of complicated wired/wireless/optical connections and "formats" and it will arrive bit-perfect and you can play it perfectly.

Another example I sometimes use is this:  If there's a typo in this post, you can be pretty sure it was me, and not due to digital corruption.

Yes, stuff can go wrong, especially with real-time transmission...  Sometimes you get a bad cell phone connection...    But, there's no reason for anything to "go wrong" inside a DAC unless the DAC is broken or poorly designed.    And when things "go wrong" with digital, they usually go horribly and obviously wrong.    Again, think about that bad cell phone connection or a "glitch" in DVD playback or with broadcast TV...    You don't get slightly-lower resolution, you get a big-nasty glitch, or it just flat-stops working.    One wrong bit in your bank account can make a billion dollar error just as easily as a 1-cent error, but it just doesn't happen.   

Unless you are building the DAC, don't worry about what's inside!   Don't worry about what chips are used or anything like that...  What matters to the user is the specs/performance.   In engineering jargon, it's a "black box".    Digital goes-in and analog-comes-out and we don't care how  it's done.    

It doesn't matter if the bridge is made of concrete, steel, or aluminum...  What matters is that it holds-up when you drive across it, and maybe how it looks.  It doesn't matter if your amplifier is made with MOSFETs or regular 'ol transistors or if it has discrete components or integrated circuits (we won't talk about tubes).  What really matters is the power, noise, distortion, frequency response, and features.   Of course, the manufacturer is going to tout any engineering decisions/trade-offs as a feature, Discrete Bipolar Class A/B Output", or "MOSFET Power!"... or whatever....



I totally agree.  I am merely trying to educate myself, so that, when a placebophile tries to tell people that they should always used optical instead of USB, I can cite some sources to prove why this is BS.

Plus I like learning new things.

I have AB tested the optical vs USB input in my DAC, and can't hear a difference.  If I had heard a difference, then I would have gone through the effort of doing some kind of blind test.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #11 –
Quote from: tedsmith on
I2S doesn't define a physical interface, but http://www.i2s.sonore.us has a chart wirings for of a good selection of DACs.
I guess this illustrates the root of the problem: I2S was invented as an interface between chips on the same printed circuit board. It wasn't destined to be an external interface between two boxes, but some manufacturers have used it to this effect, a misguided idea IMHO. The jitter argument plays into this, through manufacturers claiming that it offers lower jitter, which is equally misguided.

Jitter only matters at the point where the sampling happens (i.e. inside a DAC chip or ADC chip). It is a design engineer's job to feed a clean enough clock signal into the sampler. This question has very little to do with the external interface, be it USB or SPDIF or whatever. You wouldn't want to use an external clock input for that without any form of cleanup taking place, because you would be vulnerable to interference. Many I2S connections allow just that: They contain the clock signals separately as individual wires, so they allow their direct usage at the DAC chip. That is precisely what you don't want, jitter-wise.

So I would call a design engineer who uses the I2S interface as an interconnect between boxes incompetent, reckless or careless. Or a combination of those.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #12 –
Quote from: pelmazo on
Quote from: tedsmith on
I2S doesn't define a physical interface, but http://www.i2s.sonore.us has a chart wirings for of a good selection of DACs.
I guess this illustrates the root of the problem: I2S was invented as an interface between chips on the same printed circuit board. It wasn't destined to be an external interface between two boxes, but some manufacturers have used it to this effect, a misguided idea IMHO. The jitter argument plays into this, through manufacturers claiming that it offers lower jitter, which is equally misguided.

Jitter only matters at the point where the sampling happens (i.e. inside a DAC chip or ADC chip). It is a design engineer's job to feed a clean enough clock signal into the sampler. This question has very little to do with the external interface, be it USB or SPDIF or whatever. You wouldn't want to use an external clock input for that without any form of cleanup taking place, because you would be vulnerable to interference. Many I2S connections allow just that: They contain the clock signals separately as individual wires, so they allow their direct usage at the DAC chip. That is precisely what you don't want, jitter-wise.

So I would call a design engineer who uses the I2S interface as an interconnect between boxes incompetent, reckless or careless. Or a combination of those.


There is an audiofool belief that using an external I2S interface is superior to USB or TOSlink.  There also seems to be a belief that DACs only talk I2S and that an optical signal needs to be "converted" to I2S, which I find silly, since I2S is a protocol.  I do not believe you convert a protocol.  I would think a DAC that can hadle TOSlink connections can handle the S/PDIF protocol just fine.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #13 –
Quote from: apastuszak on
Quote from: pelmazo on
Quote from: tedsmith on
I2S doesn't define a physical interface, but http://www.i2s.sonore.us has a chart wirings for of a good selection of DACs.
I guess this illustrates the root of the problem: I2S was invented as an interface between chips on the same printed circuit board. It wasn't destined to be an external interface between two boxes, but some manufacturers have used it to this effect, a misguided idea IMHO. The jitter argument plays into this, through manufacturers claiming that it offers lower jitter, which is equally misguided.

Jitter only matters at the point where the sampling happens (i.e. inside a DAC chip or ADC chip). It is a design engineer's job to feed a clean enough clock signal into the sampler. This question has very little to do with the external interface, be it USB or SPDIF or whatever. You wouldn't want to use an external clock input for that without any form of cleanup taking place, because you would be vulnerable to interference. Many I2S connections allow just that: They contain the clock signals separately as individual wires, so they allow their direct usage at the DAC chip. That is precisely what you don't want, jitter-wise.

So I would call a design engineer who uses the I2S interface as an interconnect between boxes incompetent, reckless or careless. Or a combination of those.


There is an audiofool belief that using an external I2S interface is superior to USB or TOSlink. 

Well I2S might be pretty good, because it is used in a lot of good chips. However, there is a lot of technical opinion on this thread, which I contributed to, that cam be expanded to say that:

(1) I2S was historically speaking, developed as a protocol that is internal to an audio component like a DAC  a surround processor an AVR or some piece of professional audio production gear. It was designed to connect chips together.

(2) There was an effort to use it externally and commercialize itself as such. Its charm was that it routed the clock and the data over separate lines.  History shows that that usuage did not become mainstream.

(3)  On the one hand clock and the data do have an intimate connection between the two, and the two can be combined pretty easily. On the other hand, the data obviously is continuously varying, and with certain circuit sensitivities, the data can cause minor timing shifts on the clock that can create a subtle kind of jitter.  Separating the clock line from the data line can prevent that from happening.

(4) It is a founding principle of digital audio that subtle changes to digital data can be largely removed, usually quite simply. So if the data causes subtle shifts to the clock, they can be removed to any reasonable degree pretty easily.

(5) Along the way, digital circuit costs went down, and circuit sophistication went up, and any problems due to combining the clock and data in the same signal wire were either adequately reduced as an inherent property of the desing, or by some dedicated means such as buffering.  For example, the digital data that is output by the phototransistor circuit in an optical player is loaded with noise and jitter, but a single stage of buffering reduces it until it is vanishing.

Quote
There also seems to be a belief that DACs only talk I2S

Often true, but not exclusively true.


Quote
and that an optical signal needs to be "converted" to I2S, which I find silly, since I2S is a protocol.

Strictly speaking both optical and coax signals are frequently converted to I2S if needed by a kind of chiptat is  usually called a "Line Receiver"   This chip has become a true "Jelly bean" chip that itself costs pennies and  is found in audio gear costing well under $10.

Quote
  I do not believe you convert a protocol.  I would think a DAC that can hadle TOSlink connections can handle the S/PDIF protocol just fine.

True in spirit, if  not in every little detail or possible shading of meaning. 

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #14 –
Quote from: apastuszak on
Quote from: Arnold B. Krueger on
Please go to https://hydrogenaud.io/index.php/topic,107570.msg941578.html#msg941578  for some quick audio samples of piano with various amounts of 10 Hz jitter added.

There is a picture of a J-Test FFT for the "medium" file. The other files differ in steps of 20 dB. So this file shows the carrier at about -2 dB, and the highest sideband at about -30 dB down. The file with the next weakest jitter called "low" would have a similar sideband about 50 dB down.  The one with the weakest non-zero jitter is the "very, very low" file in which the jitter is about 90 dB down. The "reference" file has no added jitter.

The added jitter had a nominal repetition rate of about 10 Hz, and the jitter waveform is approximately triangular, which explains the complex sideband structure.

The source of the piano notes is file 39 of the SQAM files.

Thank you for the sample.  I've been trying to Google samples of jitter and not having a lot of luck.  I will play with these later today.

Enjoy!  I did a similar thing, searched the web, and came up with an Early Joni Mitchell song that had to have been mastered on analog tape that was provided by a self-proclaimed professional recording engineer of some little fame.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #15 –
Quote from: Arnold B. Krueger on
Quote from: apastuszak on
Quote from: Arnold B. Krueger on
Please go to https://hydrogenaud.io/index.php/topic,107570.msg941578.html#msg941578  for some quick audio samples of piano with various amounts of 10 Hz jitter added.

There is a picture of a J-Test FFT for the "medium" file. The other files differ in steps of 20 dB. So this file shows the carrier at about -2 dB, and the highest sideband at about -30 dB down. The file with the next weakest jitter called "low" would have a similar sideband about 50 dB down.  The one with the weakest non-zero jitter is the "very, very low" file in which the jitter is about 90 dB down. The "reference" file has no added jitter.

The added jitter had a nominal repetition rate of about 10 Hz, and the jitter waveform is approximately triangular, which explains the complex sideband structure.

The source of the piano notes is file 39 of the SQAM files.

Thank you for the sample.  I've been trying to Google samples of jitter and not having a lot of luck.  I will play with these later today.

Enjoy!  I did a similar thing, searched the web, and came up with an Early Joni Mitchell song that had to have been mastered on analog tape that was provided by a self-proclaimed professional recording engineer of some little fame.

It amazes me that you can find dozens of YouTube videos talking about the evils of jitter.  But not one of them ever shows an example of jitter that is audible.

i assume, in this day and age, any jitter produced by modern audio equipment is completely inaudible, and would not pass a proper ABX test.

Of course that never stopped audiofools from claiming that, even though you can't hear it, it still somehow impacts the human brain and somehow lessens the enjoyment of what you're listening.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #16 –
Quote from: apastuszak on
There is an audiofool belief that using an external I2S interface is superior to USB or TOSlink.
Yes. It derives from the idea that any stage in a signal chain necessarily deteriorates the signal. Since the DAC chip itself speaks I2S or a variant of it, the "reasoning" is that since any other format needs a converter circuit, it must be inferior to I2S.

This opinion is ignorant of physics and of technology. It will only appeal to those who do not understand the factors involved. The argument has some limited merit in analog signal chains, but even there it needs qualification. For example, it is well worth inserting an additional amplifier in the signal chain, if the load to be driven (i.e. a cable) is not benign. The overall signal quality will be improved by such an amplifier, even though it will add its own noise and distortion.

But here we're in digital territory. A correctly functioning digital signal chain does not deteriorate the signal at all, regardless of how many stages are involved. Reshaping and regenerating digital signals is routinely done in order to facilitate transmission. In digital technology, the audiophile reasoning is simply bunk.

USB, Toslink and other audio interfaces are designed for the job of interconnecting separate pieces of gear. I2S isn't. There's a reason for that, and only if one understands the rationale behind it, one can appreciate the merits of each technique.

Quote
There also seems to be a belief that DACs only talk I2S and that an optical signal needs to be "converted" to I2S, which I find silly, since I2S is a protocol.
There is some truth to it. The great majority of converter chips (DAC and ADC) use a variant of I2S to convey the audio in or out of the chip. Only a fairly small fraction have the ability to talk USB or Toslink directly. In this sense, yes, a "converter" is needed. But that's an advantage, since it converts to a form of interface that is optimized for external connections.

Quote
I do not believe you convert a protocol.
You do, actually. Converting between I2S and Toslink, for example, can be considered a protocol conversion.

Quote
I would think a DAC that can hadle TOSlink connections can handle the S/PDIF protocol just fine.
SPDIF and Toslink share the same protocol, only the physical interface is different. So in this case you are right. But I2S is a different protocol, and USB is different again.

Actually there frequently is misunderstanding because of sloppy usage of terminology. Strictly speaking, S/P-DIF (to use the awkward but correct punctuation at least once) is the original electrical interface devised by Sony and Philips in the 80s, using the RCA connector. Subsequently, it has been standardized as IEC 958, now ISO/IEC 60958 part 3. An optical variant was envisaged, but not formally standardized, but Toslink has been this de facto optical variant for a long time now. Effectively, the optical variant is nowadays frequently called SPDIF, too, even though the moniker, strictly speaking, applies to the old electrical interface from pre IEC 958 days.

Re: Looking to get a good explanation of the I2S protocol used by DACs

Reply #17 –
Quote from: Arnold B. Krueger on
(2) There was an effort to use it externally and commercialize itself as such. Its charm was that it routed the clock and the data over separate lines.  History shows that that usuage did not become mainstream.
It turns out that what you call "charm" is actually not a very good idea. For external connections, it is better to have data and clock use the same line. This lesson was probably learned dozens of time independently in the history of digital communications. In the meantime, with interconnects getting ever faster, the same has begun to apply even to connections on the same circuit board.

Having data and clock share the same line can save lines, but it needs an additional circuit to modulate the two together into one signal, and demodulate it at the other end. In this sense it is more complicated, so I understand why some see charm in a separated scheme. But the reward, besides a saving in lines, is that there can't be skew between data and clock, there can't be a loss of clock without a loss of data, and there can't be interference between clock and data, because they are already combined.

Quote
(3)  On the one hand clock and the data do have an intimate connection between the two, and the two can be combined pretty easily. On the other hand, the data obviously is continuously varying, and with certain circuit sensitivities, the data can cause minor timing shifts on the clock that can create a subtle kind of jitter.  Separating the clock line from the data line can prevent that from happening.
That's true in theory, but in practice it matters most how the interconnect behaves when all factors are considered together, which include external interference, too. It turns out that the combined schemes are more robust in the real world.

Quote
(4) It is a founding principle of digital audio that subtle changes to digital data can be largely removed, usually quite simply. So if the data causes subtle shifts to the clock, they can be removed to any reasonable degree pretty easily.
That's the key fact here. Both data and clock can be cleaned up at the receiving end, using long known and well established circuitry. You merely have to know your stuff as a circuit designer.