A simple cable to connect I2S over HDMI => I2S over RJ45 devices

[phile1]

Hi,

Please find below the way I managed to connect 2 devices on I2S output/input, using a simple cable.

The source is a USB>spdif interface, having a I2S output over a HDMI plug : Gustard U12
The « receiver » is a FDA (Full digital Amplifier), a QLS-Hifi QA100, having a I2S input over a RJ45 plug.

In my case, the downstream device is a FDA, it could be a DAC of course.

I do not have background in electronics, thus I just made a trial, just by connecting the right pins from each side.

The result is fairly simple : it works perfectly. No hum, no EMI that alters the sound etc.

In my case, the SQ is equal using this I2S cable connection, to a standart toslink link between the Gustar U12 & the QA100.
Thus, no gain in this exemple in using I2S.
But after discussion with others we ends up to the conclusion that it is due to the QA100 that have very good other inputs (toslink, aes, coax, bnc), this makes the difference between these standard inputs & I2S negligeable.
For instance, using I2S on another FDA like I.AM.D V200 makes the SQ much better than coax or toslink inputs.

***************************

These are photos & pics to see what I did :

Wires & color code & pin No in RJ45 & HDMI cable/connectors : basics
Basicaly, as I had no idea about pins in HDMI & RJ45 ports before that job, I just found these info thanks to our mate Google.

HDMI side :
HMDI plug => these are the pins numbers :

An externally hosted image should be here but it was not working when we last tested it.

HDMI wires inside : 7 simples wires + 4 main foiled cables each made of 3 wires
=> drawing :

An externally hosted image should be here but it was not working when we last tested it.

=> same info with pins No :

An externally hosted image should be here but it was not working when we last tested it.

=> cross section cable view :

An externally hosted image should be here but it was not working when we last tested it.

The digital data flow FROM the Gustard U12 HDMI input.
This is the info regarding the pins No & functions on its I2S/HDMI ouput.
It is available on the seller web page.
Of course you need that info to go forward ; I don’t know if these relation pins No vs function is commom to all manafacturers… I would say so. Ask for the manufacturer of your device to be sure.
=> layout :

An externally hosted image should be here but it was not working when we last tested it.

RJ45 side :
The digital data flow TO the QA100 I2S input over RJ45 plug.
This is the info regarding the pins No & functions on its input :
=> simple photo on the QA100, you have all the info =>

An externally hosted image should be here but it was not working when we last tested it.

RJ45 cables & pins :
1st, I noticed there are 3 types of RJ45 connectors, with the references : EIA-568-A or -B or -C.
These are the differences, it is about a change in the pins No (FYI)
=> 1st type => EIA-568-A & -C

An externally hosted image should be here but it was not working when we last tested it.

=> 2 type : EIA-568-B

An externally hosted image should be here but it was not working when we last tested it.

Photo of the RJ45 I used, it is a B type, and the color code you can see through is OK :

An externally hosted image should be here but it was not working when we last tested it.

Tricky point : on the 2nd RJ45 cable I tested, it was written on its side it was a « C » type, but the wire colors you could see thru the connectors indicated that it was a « B » type, thus I connected it like a B type and it was OK. So, check this.


Which wire on HDMI side corresponds to which wire on RJ45 side ?
Basically, according to the photo of the QA100, the I2S on the RJ45 side requires only 5 wires (http://img15.hostingpics.net/pics/88250820151119154231.jpg ) :
pin1 = LRCK
pin3 = DATA
pin5 = BCK
pin7 = MCLK
all other pins = ground

On HDMI side, you have, according to this diagram http://img15.hostingpics.net/pics/644095GustardU12HDMIpinscode.jpg you have more « useful » pins.
For instance, you have a +5V pin, and 4 pairs => DATA+ & DATA -, BCLK+ & BCLK- etc…
So, to make it simple, I thought it is a good idea to let the RJ45 port to lead that connection !
Thus :
I don’t care about +5V pin on the HDMI side, I don’t care either about the DATA- BCLK- etc…
I found nice & straight forward to connect : DATA (on RJ45) to DATA+ (on HDMI) etc… and connect 1 ground pin on the RJ45 to 1 ground pin on the HDMI side.

This is it.
Then I just had to find & connect the wires like described above.


Inside RJ45 & HDMI cable/connectors : wires ID

Inside HDMI cable :
- take off the PVC => http://img15.hostingpics.net/pics/75532020151121231715.jpg
nice shield + foil
- open the foil => http://img15.hostingpics.net/pics/32240820151121232323textarrow.jpg
you have the 4 groups of 3 wires, as it was showed on this drawing (« + » pin, « -« pin, and ground> http://img15.hostingpics.net/pics/551890HDMIcablefrontviewPinsNofunctions.jpg
- please note that the color of foils & inside wires does not match the diagram I found, this one : http://img15.hostingpics.net/pics/740755HDMIcablecolorscode.jpg
thus, the game was to guess > trial > error > trial. 2 small mistakes, but no time lost on this.

Inside RJ45 :
let’s look at a SSTP cable. As said above regarding RJ45, you have 8 pins, corresponding to 4 pairs of 2 cables.
take off the PVC => you found a shield (it is cut on this photo) => inside the 4 pairs, foild => inside this tiny foil, you find a pair.
=> http://img15.hostingpics.net/pics/60183620151122164714.jpg
According to the pins used in the I2S connection written on the QA100, and the basic data regarding RJ45 plug B type, you realise you need only to deal with the white wires, the other ones will correpond to « ground ».

Usually, each pair is : full color on 1 wire, and color/white on the other wire ; easy to distinguish all these 8 wires.
In my case, in this exemple, no « color/white » wires… they are only white… no a big deal to distinguish & avoid a complete mess between all these full white wires, but really annoying that « color code » seems to be « optional » whatever the cable producer…

Look at the connection : http://img15.hostingpics.net/pics/42762820151122164803.jpg
the orange wire is on the pin2 => it is a B type cable (although it is written « C type » on the cable…). Thus you know which wire at the cable end correponds to the pin at connector side.


1st connection trial : wire to wire

The 1st test consisted in connecting the 2 cables like this :

An externally hosted image should be here but it was not working when we last tested it.

Fairly basic & easier to test the right link between pin & cables. For instance, useful when pins No & ID given by the manafacturer of the interface or/and the downstream device are not correct.
I made a mistake and inverted on the HDMI side the wire from the green foil (LRCK in fact) & the silver foil (BCK in fact) : I had some sound, but full of EMI etc…After inversion => dead clear & nice sound.


2nd & final connection trial : RJ45 wires on HDMI connector

The 1st trial allowed to understand the pin/wire links & ID.
Then, to have a ready to use cable, with EMI as low as possoble, I needed to soldier it somehow.
The best way I found was to soldier the RJ45 wires on the HDMI connector.

HDMI connector : inside
this is the connector =>

An externally hosted image should be here but it was not working when we last tested it.

you have some silicone aournd to take off…
then take off the pins you do not need using cutter & clamp.
As seen before, I chose to deal with the pins of the HDMI, only the DATA+, BCLK+, LRCK+ ; MCLK+ (seen here : http://img15.hostingpics.net/pics/644095GustardU12HDMIpinscode.jpg )

ATTENTION : I kept 1 pin links to the ground.
Because on this photo => http://img15.hostingpics.net/pics/52331920151122100016.jpg for fun, I cut the ground link => big hum => I wired back 2 ground wire (1 from each cable) => no hum => nice & clear sound

So finally, I have the super nice HDMI connector
side 1 => http://img15.hostingpics.net/pics/53591120151122153356.jpg
side 2 => http://img15.hostingpics.net/pics/68408520151122153414.jpg ; here the non-green wire is the ground.

RJ45 cable prepared for soldering.
the RJ45 is fully open, no sheild, foild etc…. Ready to be soldiered on the connector => http://img15.hostingpics.net/pics/97436520151122174440.jpg
The trickiest part of the job for a newbie in soldering is ahead…

Note that on this photo you have 2 RJ45 cables.
Why ? because I have 2 QA100 amp. 2 FDA used in passive BI-AMPLICATION for my floorstanding speakers.
The nice thing with this type of cable & I2S connection is that, as mentioned Globulegl on a other thread, there is NO ISSUE regarding impedance voltage etc… too tricky stuff for newbies…
With I2S, just soldier 2 RJ45 cable on 1 HDMI connector, and data will flow without any issue from the HDMI interface to the 2 device downstream on RJ45 port, in sync : perfect solution for spliiting digital audio. Much cheaper than optical splitter of course, & even more cheap than my Mutec MC1.1+ (but the Mutec MC1.1+ can handle inputs… with this cable, you split only the I2S)

RJ45 cable soldiered on the HDMI connector
side 1 =>

An externally hosted image should be here but it was not working when we last tested it.

Side 2 =>

An externally hosted image should be here but it was not working when we last tested it.

So, as you can see :
- the blue wire, alone on the ground pin
- and 2 wires soldiered on each pin, because 2 RJ45 cable for my biamp.
- dots on the white wires, it was to distinguish the color of each pair (given than in that bloody cable, the color/white wires were fully white…)


RJ45 wires & HDMI pins combination

Thus, the combination to link the Gustard U12 to the QA100 is the following :

HDMI connector.
As mentionned above, on RJ45 side we need 4 « active » pins (thus 4 wires) + 1 for the ground.
Thus on the HDMI connector, I kept the following pins : No 1 - 4 - 7 - 10, for the « active wires » ; and the pin 11 to connect the ground.
Reminder, see here the pins No & location on the connector =>

An externally hosted image should be here but it was not working when we last tested it.

On the HDMI pin 1 (DATA+), you connect the RJ45 pin 3 ; white/green wire of the RJ45 cable type B; or the white one in the foill where you have the green wire.
On the HDMI pin 4 (BCLK+), you connect the RJ45 pin 5 ; white/blue wire of the RJ45 cable type B; or the white one in the foill where you have the blue wire.
On the HDMI pin 7 (LRCK+), you connect the RJ45 pin 1 ; white/orange wire of the RJ45 cable type B; or the white one in the foill where you have the orange wire.
On the HDMI pin 10, you connect the RJ45 pin 7 ; white/brown wire of the RJ45 cable type B; or the white one in the foill where you have the brown wire.
On the HDMI pin 11 (for instance, or another one linked to ground according the Gustard U12 info), you connect a full colored wire of the RJ45 cable, I chose blue…

As you can see on this photo for instance, my soldering is pretty awful, but it works… so why bother with I2S ?...

***********************************************

Sorry if this post is too long and/or not clear. Feel free to ask if you can’t catch a word about this tricky but simple connection.
Hope it helps
Rgds

 

[Arledgsc]

I'm surprise this connection even works as it does not seem like the HDMI LVDS drivers have enough voltage swing to match the wider TTL voltage level inputs on the RJ45 input. Plus the LVDS drivers are differential where 3.5mA of current passes one direction or the other for digital 1's and 0's. This means the negative side of the LVDS pair is required to complete circuit. And LVDS has a voltage offset above ground. But I take your word for it but would like to see the resultant waveform on an oscilloscope before declaring victory. If the o'scope reveals not so perfectly square signals you are probably introducing jitter which is whole point of LVDS in the first place.

 

[kASD]

Phile 1 You fail to anwser the above question ..........

 

[hy2a3]

Phile 1 Nice write-up. Found your guide very helpful.

 

[Gusser]

.... In my case, the SQ is equal using this I2S cable connection, to a standart toslink link between the Gustar U12 & the QA100.
Thus, no gain in this exemple in using I2S. … so why bother with I2S ?...

Rgds

I completely agree. You say it sounds identical to SPDIF or USB and it should.

I2S is an internal device protocol to interconnect audio processing chips. It was never intended to leave a box and you will never find I2s ports on professional gear except for perhaps a test jig that tests I2S.

This I2S over CAT5 and HDMI cable is just another audiophile hack. The problems it is said to fix, such as jitter, are't a problem in the first place - as you discovered. Sure the measured jitter form an I2s connection (on a proprly designed PC board, not one of these external hacks) will be lower, but the Jitter from a reasonable USB or SPDIF/AES is already inaudible.

You are lucky it does sound identical cor USB or SPDIF. It could easily sound worse. By running I2S over long cables there is a good chance of skewing the timing relationship between the I2S signals. Furthermore not using proper line drivers and receivers such as you did invites even more data errors.

The people that come up with the I2S hacks probably don't even own a scope let alone know what to look for.

 

[Gusser]

I'm surprise this connection even works as it does not seem like the HDMI LVDS drivers have enough voltage swing to match the wider TTL voltage level inputs on the RJ45 input. Plus the LVDS drivers are differential where 3.5mA of current passes one direction or the other for digital 1's and 0's. This means the negative side of the LVDS pair is required to complete circuit. And LVDS has a voltage offset above ground. But I take your word for it but would like to see the resultant waveform on an oscilloscope before declaring victory. If the o'scope reveals not so perfectly square signals you are probably introducing jitter which is whole point of LVDS in the first place.

He is grounding the LVDS- leg. So it basically forcing the LVDS to run unbalanced. The reason it works to spite the voltage mis-match is because I2S is rather low bandwidth and very forgiving.

 

[DF96]

Someone somewhere started a meme that I2S is 'better' than SPDIF, when the truth is that it is different: aimed at quite a different application. My understanding is that I2S doesn't even define a characteristic impedance, so it is quite impossible (apart from luck or guesswork) to send it over a cable of more than a trivially short length without getting reflections and hence jitter. It may be that the people who do this sort of thing would not know a characteristic impedance if one dropped on their foot.

RJ45 is a connector, not a cable. Perhaps by 'RJ45' people mean 'a Cat X cable meant for Ethernet'?

As has been said, it is only because digital audio interfaces are so robustly engineered and relatively uncritical that using the wrong techniques or wrong cables can be tolerated. Using the right technique (I2S short distance on board, SPDIF longer between cabinets) with the right cable is so boring and conventional that surely it must destroy the music?

 

[Gusser]

Someone somewhere started a meme that I2S is 'better' than SPDIF, when the truth is that it is different: aimed at quite a different application. My understanding is that I2S doesn't even define a characteristic impedance, so it is quite impossible (apart from luck or guesswork) to send it over a cable of more than a trivially short length without getting reflections and hence jitter. It may be that the people who do this sort of thing would not know a characteristic impedance if one dropped on their foot.

RJ45 is a connector, not a cable. Perhaps by 'RJ45' people mean 'a Cat X cable meant for Ethernet'?

As has been said, it is only because digital audio interfaces are so robustly engineered and relatively uncritical that using the wrong techniques or wrong cables can be tolerated. Using the right technique (I2S short distance on board, SPDIF longer between cabinets) with the right cable is so boring and conventional that surely it must destroy the music?

Well I would loosely call I2S a TTL interface. Of course what does that mean today?

5v / 3.3v? old standard TTL, F TTL (probably not), LS TTL, HC TTL, ??? As always the specific chip data sheet is you friend and it will list the drive capabilities for each and every pin.

P.S. I guess there is really no such thing as 3.3v TTL as when 3.3v came around, everything was CMOS.

 

[marce]

I2S is was designed as an inter chip serial interface for use on a single PCB, it was never designed as an interface for transmitting over cables... That's what SPDIF was for. It is a relatively slow digital signal with an allowable rise time of up to 60ns. If you are transmitting it over cables I would go for the best impedance match through the PCB, connectors, cable, connectors, PCB usually 50R. If I was inclined to put I2S over a cable I would use twisted pair for each connection, with a separate return line for each signal as part of the twisted pair to ensure a good signal/return path coupling.

https://web.archive.org/web/20070102004400/http://www.nxp.com/acrobat_download/various/I2SBUS.pdf

What is a TTL interface, its a digital interface it just stands for transistor transistor logic, as you state the drive strength is what is critical for sending a signal longer distances, in conjunction with the signal path and impedance. TTL was bipolar transistors hence the power supply being labelled VCC (voltage collector collector) and why CMOS devises power are labelled VDD (Voltage Drain Drain, and VSS for negative/0V).

RJ stands for register jack a standard telecommunication interface using a specific cable/connector combination, in this case a modular jack 8/8 (8 pins all used).

 

[jean-paul]

I2S was meant to be used between chips (not devices) but it certainly has advantages over SPDIF. Long distances were practically impossible till an engineer gave it some thoughts. A good working I2S over HDMI system (so suitable for cables/wires longer than 10 cm) by means of LVDS transmitters and receivers was more or less developed by PS Audio and can be used by anyone. I recall one of their engineers reporting here that the schematics can be used freely. It works very good BUT it requires serious surgery on the case of devices, some signal finding and of course enough space. HDMI cables are technically quite OK and they are cheap as they are produced in extremely high numbers. This makes I2S over HDMI an interesting choice compared to USB, SPDIF etc. We can only hope that it will be a kind of standard interface as it works OK. It is not a "hack" as stated here as it was developed by a serious audio company. Please check the attached schematics.

A solution could have been to change the input connector of the QLS QA-100 to a HDMI one with LVDS receiver putting out plain I2S signals. OP found the proposed solution in 2015 so things already work one way or another. Despite having used I2S over HDMI I ended up still working with the inferior SPDIF because ease of use and not needing to operate every new device I get my hands on.

http://www.diyaudio.com/forums/digital-source/237690-ps-audio-i2s-interface.html

HDMI to I2S Module - Audiophonics

 

[Gusser]

I2S was never meant to be used between devices but it has advantages over SPDIF. Long distances were practically impossible till an engineer gave it some thoughts. A good working I2S over HDMI (so suitable for cables/wires longer than 10 cm) by means of LVDS transmitters and receivers was more or less developed by PS Audio and can be used by anyone. I recall one of their engineers reporting here that the schematics can be used freely. It works very good BUT it requires serious surgery on the case of devices, some signal finding and of course enough space. HDMI cables are technically quite OK and they are cheap as they are produced in extremely high numbers. This makes I2S over HDMI an interesting choice compared to USB, SPDIF etc.

A solution could have been to change the input connector of the QLS QA-100 to a HDMI one with LVDS receiver putting out plain I2S signals. OP found the proposed solution in 2015 so things already work one way or another. Despite having used I2S over HDMI I ended up still working with the inferior SPDIF because ease of use and not needing to operate every new device I get my hands on.

http://www.diyaudio.com/forums/digital-source/237690-ps-audio-i2s-interface.html

HDMI to I2S Module - Audiophonics

PS Audio?

Again there is no professional implementation of I2S interconnecting audio components. Professionals use AES which is exactly the same as SPDIF in terms of performance.

This idea is yet another unwarranted jitter scare by people who do not understand the underlying electronics at play. Furthermore that lack of electronics knowledge means the proponents of I2S external ports fail to see the true pitfalls of this approach.

A far larger problem clearly understood by communications engineers is signal skew. By running parallel signals over long cables you end up with path length differences. And since I2S is running at video rates, especially in the higher sample rates, it it subject to classic transmission line effects. Additionally twisted pair cable is very difficult to manufacture with a predictable twist length further aggravating this issue. When twisted pair cables are used where signal skew is an issue, the receiving device uses a FIFO to re-align the streams. I2S does not employ this technology because data skew doesn't happen at these rates on an average PC board.

This is a classic audiophile hack taking a non-existent problem (SPDIF jitter) and making it worse by kludging together a solution that is not recognized by the professional electronics community - for the reasone I outlined above.

 

[jean-paul]

No professional implementation on itself does not say too much. When things simply work changing to a different interface in the professional world is not easy. AES/EBU and SPDIF were not designed for optimal performance but for single cable use/low cost/simplicity. Secondly this "PS Audio I2S over HDMI" is meant as interface with relative short cables between consumer devices and not for tens of metres cabling. It probably will not work OK over very long distances for the reasons you mention. PS Audio uses this on its devices and I can only testify that it works OK with cheap cabling as a bonus. SPDIF sure has jitter, this is inherent to the system. Most device internally are I2S which must be converted to SPDIF serial signal. At the receiving end serial signals must be taken apart again and converted to I2S again. Using I2S over HDMI skips those 2 conversion steps. If I would buy new devices that have the I2S over HDMI interface I would use that one without second thoughts. I am surprised to see someone defending SPDIF which by now seems to be the most flawed interface in audio.

I think discussion is pointless but anyone that experiments with SPDIF and I2S over short distances will experience I2S being superior. They will also very likely tell that it is very sensitive to long cabling. People that have PS Audio or other devices with I2S over HDMI also seem to prefer it over the other interfaces.

 

[Gusser]

.... I am surprised to see someone defending SPDIF which by now seems to be the most flawed interface in audio.

.....

Flawed by who's point of qualified view? Audiophile magazines? AES is the standard interface for all mastering and broadcast systems. Any material you choose to listen to that arrived in a digital format has been through thousands of feet of AES interfaces by the time you play it.

Now there are some pretty crappy SPDIF interfaces out there and their jitter can be rather high. But any competently designed AES/SPDIF interface will have jitter levels below audibility. Otherwise it would hardly be acceptable in professional environments.

Furthermore an AES / SPDIF interfcae uses Manchester encoding. Many, many communications protocols are based on Manchester encoding. And even high speed interfaces use it but with enhancements to further recover the clock at high data rates - of which AES and SPDIF don't have that issue.

Are ATA and SCSI parallel disk interfaces superior to SATA and SAS? The primary reason they went to these technologies was not just to make cabling simpler. The costs are probably a wash. At the required data rates, parallel interfaces simple don't perform over cables of even a foot long. I suppose based on this statement the next audiophile craze will be to use old ATA disk drives because SATA has too much jitter for good digital audio! Give me a break!

 

[jean-paul]

You can try both SPDIF and I2S short distance and try yourself. It is quite convincing. I think the I2S over HDMI system is a nice enhancement of the impracticality of using I2S with cabling longer than a few centimetres. It performs better than SPDIF and so do other recent interfaces. High jitter with SPDIF receivers is an item that simply can not be ignored. Some perform better than others. It is jittery and the fact that it is used in studios does not say anything about its quality, it is up to the task and no more than that. It was the standard then and the industry does not seem to care for a better system apart from some lone souls. Even Elektor magazine designed an SPDIF jitter meter in the eighties, not long after SPDIF was implemented. The jitter numbers of most SPDIF receiver chips are well known and published in datasheets. I built SPDIF systems with a feedback loop to reduce jitter numbers in the nineties which were switchable between normal and feedback operation (PLL like). Clearly audible and clearly measurable. If only it had been designed with just one more shielded conductor for the clock signal from the start...

*SATA was developed because of the required very high speed and then parallel interfaces become problematic. PATA cabling was not designed to be shielded which did not help. Last attempt was to implement GND conductors between signal cables but crosstalk and other problems still occurred. Different subject though as the relatively slow audio digital signal is hardly comparable with SATA interface data bandwidth.

"Professional" does not say all. I have seen a professional studio where recordings are made in MP3 format. When I asked why they did not use lossless formats they said they did not bother, the CD would be pressed by converting the MP3 file !

 

[Gusser]

You can try both SPDIF and I2S short distance and try yourself. It is quite convincing. .

But when I see intermod components at -130db or lower measured on AES interfaces, I hardly see the need for improvement. What is the noise floor of your power amp? How about your listening room? This is clearly not audible and can be achieved with AES and SPDIF interfaces.

I also can't fathom why any recording studio, even a low budget garage operation, would record in MP3. With the price of storage these days there is no reason not to use PCM at 24bit and even 192khz, although 96khz is more than good enough IMO. I don't doubt you saw that being done, it just baffles me that anyone would do that.

 

[marce]

Is there any proof of one digital interface being better than another, real proof not just anecdotal evidence?

 

[jean-paul]

Sorry I am not on the position to be able to prove anything. Like almost always is the case being an amateur. I don't have the equipment to measure jitter. It is just good experiences which is not that hard when comparing with SPDIF. I tried to find some measurements on the web but except quite good reviews of equipment with I2S over HDMI no real proof. SPDIF exists a little longer and proof of jitter can be found. In fact my own measurements in the past and experiences and still using dinosaur SPDIF make me very aware of its limitations. No need to be a scientist to see where it goes wrong. It just works but it could have been designed better. In the past 200 ps till 1 ns jitter was quite normal, now we have receivers that are between 50 and 100 ps. Still quite high compared to devices with internal DACs and internal I2S. For this reason any identical source that exists in a version with internal DAC and a version with external DAC will show the version with internal DAC to perform better. Believe me I tried. More than once too.

New techniques are easily accepted here so market acceptance of I2S over HDMI is no issue contrary some more conservative areas. First experiences were with the RAKK DAC that used the PS Audio protocol/system. I2S over HDMI wins from SPDIF hands down and in many cases also from USB. If the ears detect it measurements should easily prove the same results. There are many projects of DIYers adding I2S over HDMI to existing sources, also here on diyaudio.com. The list of manufacturers using it on products is growing too if that says something.

The I2S over HDMI interface must be doing something good:

[Review] Pink Faun I2S Bridge - Computer to DAC Interface

 

[jean-paul]

*Please note that I2S over HDMI is also quite old by now, we are debating implemented and accepted technology that already sets the standard at many audio brands like Wadia. Not being familiar with it is not the fault of this interface.

Like always in life one standard was not enough so I2S over ethernet also exists. No experience with that one.

 

[marce]

I was wondering about all the digital interfaces including USB, as all methods have a mix of people for and against... The trouble is not just the sending of the data, the quality of the receiver would also have to be factored in, so comprehensive measurements would be a big task.
A good example of "problematic" parallel interface would be the DDR memory interface. Though I have worked on high speed cable based interfaces, using double sided FFC cables, signals one side return (GND) on the other, but there is a length limit depending on the signal, and its not as cheap as a LVDS serial interface, though the data input can be very impressive.
Actually putting signals down wires using LVDS is often done, especially for some high end test gear, usually custom, but for a simple interface to a DAC it just seems overkill to me....

 

[Gusser]

....Like always in life one standard was not enough so I2S over ethernet also exists. No experience with that one.

Well one version of that is nothing more than RS422 or LVDS over RJ45 CAT 5 cable. 4 pairs fits the application nicely.

But note what I said above about skewing. In CAT5E cable the pairs are deliberately set at different twist lengths to minimize crosstalk. Specifically what you don't want for an I2S application.

If somebody wants to do this right, I would suggest a FIFO and control logic be placed at the receiver that will re-align the edges back to the I2S spec. That can easily fit in a low cost FPGA these days.