I2S isolation

[Keened]

I am somewhat confused about the tolerances required for I2S galvanic isolation.

Originally I thought it would be as simple as taking the I2S pinout and running each leg through an electro-optical isolator like this 4/0 since the data flow is unidirectional in this case. Then you would take the output and feed it to the next system.

But then I started looking into the tolerances required to be transparent to the I2S slaved receiving chip and became less sure. This paper implies there are three main issues with electro-optical isolation:

1. Rise and Fall minimum times to ensure each clock beat is sampled and reproduced (required minimum times dictated by the MClk)
2. Propagation time across the isolator (which if every line is subject to the same delay isn't an issue except for live latency)
3. Saturation delays introduced specifically by electro-optical isolation which can be fixed by maintaining a partial load on the diodes and/or using a different form of isolation like capacitive coupling. This one matters mostly if you're using I2S in a bidirectional fashion

If you're sampling an 8 channel@48khz signal there will be 8 I2S channels: 4 data channels, 2 'polarity/frame' channels/a 'left' and a 'right' clock, and 2 timing (a frame/word clock and Master clock). The lower boundary will be set by the MClk since it will be the highest frequency signal and all other clocks will be a divisible subset of it.

So I believe I need to use a chip that supports up to 6.144 Mhz. Worst case scenario using the first chip is:

(1 bit) per (30 nanoseconds) = 4.16666667 MBps or 33.3333334 Mbps. Assuming 1 bit per hz as the worst efficiency/naively encoded it should have enough overall bandwidth (33Mhz) and the saturation delay shouldn't be an issue so long as every signal has the same delay and the frames are being asynch reclocked on the other end. The range of delay however is somewhat variable but still should fall within the tolerances if we're only using a 6Mhz signal I think.

There are other isolators like this digital isolator which has a smaller rise and fall time but the total transit across the chip is larger and the pulse distortion doesn't seem like it would be much better?

 

[mansr]

What about Texas Instruments ISO7740?

 

[Keened]

What about Texas Instruments ISO7740?

I wasn't looking at this because I filtered for chips in stock on Digikey and thought electro-optical was the gold standard for absolutely no good reason apparently.

Yeah, that looks like it will work very well. Faster transitions, longer life, and cheaper to boot...what's the catch? I see on the datasheet I have to choose if it defaults high or low with no signal but that's not a catch, that's just choosing the right parts.

MHL HDMI ports can provide 5v power and this uses such tiny amounts of current so you might even be able to make it a 'self-powered' isolator for short runs...

 

[Roland68]

I am somewhat confused about the tolerances required for I2S galvanic isolation.

Originally I thought it would be as simple as taking the I2S pinout and running each leg through an electro-optical isolator like this 4/0 since the data flow is unidirectional in this case. Then you would take the output and feed it to the next system.

But then I started looking into the tolerances required to be transparent to the I2S slaved receiving chip and became less sure. This paper implies there are three main issues with electro-optical isolation:

1. Rise and Fall minimum times to ensure each clock beat is sampled and reproduced (required minimum times dictated by the MClk)
2. Propagation time across the isolator (which if every line is subject to the same delay isn't an issue except for live latency)
3. Saturation delays introduced specifically by electro-optical isolation which can be fixed by maintaining a partial load on the diodes and/or using a different form of isolation like capacitive coupling. This one matters mostly if you're using I2S in a bidirectional fashion

If you're sampling an 8 channel@48khz signal there will be 8 I2S channels: 4 data channels, 2 'polarity/frame' channels/a 'left' and a 'right' clock, and 2 timing (a frame/word clock and Master clock). The lower boundary will be set by the MClk since it will be the highest frequency signal and all other clocks will be a divisible subset of it.

So I believe I need to use a chip that supports up to 6.144 Mhz. Worst case scenario using the first chip is:

(1 bit) per (30 nanoseconds) = 4.16666667 MBps or 33.3333334 Mbps. Assuming 1 bit per hz as the worst efficiency/naively encoded it should have enough overall bandwidth (33Mhz) and the saturation delay shouldn't be an issue so long as every signal has the same delay and the frames are being asynch reclocked on the other end. The range of delay however is somewhat variable but still should fall within the tolerances if we're only using a 6Mhz signal I think.

There are other isolators like this digital isolator which has a smaller rise and fall time but the total transit across the chip is larger and the pulse distortion doesn't seem like it would be much better?

Is it about i2s or i2s over LVDS?
May I ask why you want to galvanically isolate i2s?
The linked document is for the i2c bus which is used for control and communication but not for transferring audio data.

 

[Keened]

Is it about i2s or i2s over LVDS?
May I ask why you want to galvanically isolate i2s?
The linked document is for the i2c bus which is used for control and communication but not for transferring audio data.

In truth, I did not make a distinction between I2C vs I2S when doing cursory searching for information about isolation. Both are clocked low voltage digital signals so I figured it was just about finding a chip that ran fast enough at the right voltages with enough physical channels.

It will be i2s over LVDS/HDMI cabling; I'm extracting audio data from an HDMI stream and there will be various components ahead of it with unknown grounding configurations. From what I understand it's a real pain to galvanically isolate HDMI directly since it pushes multiple Gbps on the data channels, but once you've extracted just the audio data out you're dealing with much more reasonable bandwidth.

EDIT: Stock times for that chip are next year at the moment from all major retailers

 

[Roland68]

In truth, I did not make a distinction between I2C vs I2S when doing cursory searching for information about isolation. Both are clocked low voltage digital signals so I figured it was just about finding a chip that ran fast enough at the right voltages with enough physical channels.

It will be i2s over LVDS/HDMI cabling; I'm extracting audio data from an HDMI stream and there will be various components ahead of it with unknown grounding configurations. From what I understand it's a real pain to galvanically isolate HDMI directly since it pushes multiple Gbps on the data channels, but once you've extracted just the audio data out you're dealing with much more reasonable bandwidth.

EDIT: Stock times for that chip are next year at the moment from all major retailers

i2s over LVDS over an HDMI connector has absolutely nothing to do with HDMI other than the physical connector.
I2C is a master slave bus system for communication.
Both PCM and DSD can be transmitted via normal HDMI.
If you want to galvanically isolate i2s over LVDS then you will have to deal with LVDS. Search for "Galvanically Isolated LVDS Interface Circuit".
Analog Devices' ADN4650/1/2 dual-channel LVDS isolators (ADN4650/ADN4651/ADN4652) may be a better approach.
In principle, the ADI technical support forum, but also the EngineerZone and the technical documents are a good source of information for such developments.
A link to an HDMI extraction board on Aliexpress:
HDMI extraction board
And an converter board back to "normal" i2s:
HDMI LVDS to i2s

 

[sq225917]

Before wasting time and money why not check to see that you have an issue that needs fixing?

 

[Keened]

i2s over LVDS over an HDMI connector has absolutely nothing to do with HDMI other than the physical connector.
I2C is a master slave bus system for communication.
Both PCM and DSD can be transmitted via normal HDMI.

A link to an HDMI extraction board on Aliexpress:
HDMI extraction board
And an converter board back to "normal" i2s:
HDMI LVDS to i2s

Yes, the plan is to just use the I2S-over-HDMI port out on this extraction board for multi-channel audio, then use a female HDMI port breakout board to wire as appropriate to a I2S-USB conversion board (using pre-cut/terminated 3" ribbons, not quite as good as printed circuits but should be sufficient). I should be more strict in my language usage since I realize I'm now adding confusion:

Physical layer: HDMI cable -> BlackBox -> shielded HDMI/LVDS cabling -> Female HDMI/LVDS breakout board -> manual pinout to I2S on USBStreamer via pre-terminated ribbon wire

Electrical layer: LVDS/Differential up to 3v -> BlackBox -> I2S@up to 3.3v -> 3.3v unbalanced -> digital signal amplifier/isolation -> 5v unbalanced -> Stepdown

Information layer: HDMI encoded -> BlackBox -> I2S synch -> USBStreamer Async PCM conversion

The issue however, as seen in Michael's experiment in a similar vein is a less than ideal signal strength and/or s/n ratio. HDMI operates on such a high frequency signals (165Mhz minimum in the 1.0 standard with a 10x synthesized clock to pick it even further apart) and has error correction that I suspect it has no issue cleaning up weak or malformed signals (i.e. slow rise/slow fall) since it gets so many more positions to poll the data before decoding and re-creation of the payload.

People talk about the audio being inserted in an 'analog' fashion into HDMI but I think that's a misunderstanding that comes from the signal being sent over differential/'balanced' which has +,-, and neutral so it looks like a normal full waveform rather than a V+/V0 'digital' signal.

Since the I2S out isn't a balanced signal and it's not carrying encoded frames with error reduction you can only try to reduce the background noise and boost the voltage to send the signal further. Since it's a synchronus protocol any changes you make in the time domain have to be transparent, so constant delay on all lines with small enough variance to never desync. Ideally you would run the bus fast enough that you could introduce a blanking resync 'frame' every n word clocks to reset any incremental drift but that's getting into custom design which I am clearly not qualified for.

The TI chips you linked earlier would actually do that very well I believe since they would:

• Drop ground loop noise introduced by the change to a single ended signal
• Clean up malformed digital signal/square waves
• Re-transmit a clean square wave at 5V
• Step down to 3.3v if required by the USBSteamer

I'd just have to make sure the run lengths are as even and as short as possible, so I was going to use 75mm pre-terminated ribbon cables. Unfortuneately they're out of stock so...

If you want to galvanically isolate i2s over LVDS then you will have to deal with LVDS. Search for "Galvanically Isolated LVDS Interface Circuit".
Analog Devices' ADN4650/1/2 dual-channel LVDS isolators (ADN4650/ADN4651/ADN4652) may be a better approach.
In principle, the ADI technical support forum, but also the EngineerZone and the technical documents are a good source of information for such developments.

Those would work well on the HDMI in, but less so on the I2S out from the board. Do you think it's worth trying to isolate the HDMI in first? Or should I see about an intermediate transport chip pair that muxes the I2S into a differential signal to transport between the blackbox and usbstreamer and use these to isolate it in between? I feel we shouldn't need to for such short interconnect runs but maybe the shielding from induced noise is worth it?

The main issues that I can see (and that @mdsimon2 ran into) are:

Signal Strength: Voltage drop and noise floor
Signal Integrity: Signal shape/malformed edges
Clock Recovery: Drift from missing edge locks due to poor signal integrity and physical run mismatch drift

I was thinking:

Fixing signal strength: Increase the V+ amplitude with a carrier wave (requires hysteresis curve information to remove on the other end, the TI chips have this included), minimize the cable length to minimize voltage drop, and isolate ground loops to drop the noise floor.
Signal integrity: Re-generate the digital signal and clock before transmitting and/or after receiving before passing on.
Clock Recovery: Poll the received signals at a higher frequency and regenerate the clock based on the expected relation between WordClock and the BitClock. Minimize physical run difference or use a 'learning' bus that can adjust.

 

[Roland68]

Yes, the plan is to just use the I2S-over-HDMI port out on this extraction board for multi-channel audio, then use a female HDMI port breakout board to wire as appropriate to a I2S-USB conversion board (using pre-cut/terminated 3" ribbons, not quite as good as printed circuits but should be sufficient). I should be more strict in my language usage since I realize I'm now adding confusion:

Physical layer: HDMI cable -> BlackBox -> shielded HDMI/LVDS cabling -> Female HDMI/LVDS breakout board -> manual pinout to I2S on USBStreamer via pre-terminated ribbon wire

Electrical layer: LVDS/Differential up to 3v -> BlackBox -> I2S@up to 3.3v -> 3.3v unbalanced -> digital signal amplifier/isolation -> 5v unbalanced -> Stepdown

Information layer: HDMI encoded -> BlackBox -> I2S synch -> USBStreamer Async PCM conversion

The issue however, as seen in Michael's experiment in a similar vein is a less than ideal signal strength and/or s/n ratio. HDMI operates on such a high frequency signals (165Mhz minimum in the 1.0 standard with a 10x synthesized clock to pick it even further apart) and has error correction that I suspect it has no issue cleaning up weak or malformed signals (i.e. slow rise/slow fall) since it gets so many more positions to poll the data before decoding and re-creation of the payload.

People talk about the audio being inserted in an 'analog' fashion into HDMI but I think that's a misunderstanding that comes from the signal being sent over differential/'balanced' which has +,-, and neutral so it looks like a normal full waveform rather than a V+/V0 'digital' signal.

Since the I2S out isn't a balanced signal and it's not carrying encoded frames with error reduction you can only try to reduce the background noise and boost the voltage to send the signal further. Since it's a synchronus protocol any changes you make in the time domain have to be transparent, so constant delay on all lines with small enough variance to never desync. Ideally you would run the bus fast enough that you could introduce a blanking resync 'frame' every n word clocks to reset any incremental drift but that's getting into custom design which I am clearly not qualified for.

The TI chips you linked earlier would actually do that very well I believe since they would:

• Drop ground loop noise introduced by the change to a single ended signal
• Clean up malformed digital signal/square waves
• Re-transmit a clean square wave at 5V
• Step down to 3.3v if required by the USBSteamer

I'd just have to make sure the run lengths are as even and as short as possible, so I was going to use 75mm pre-terminated ribbon cables. Unfortuneately they're out of stock so...



Those would work well on the HDMI in, but less so on the I2S out from the board. Do you think it's worth trying to isolate the HDMI in first? Or should I see about an intermediate transport chip pair that muxes the I2S into a differential signal to transport between the blackbox and usbstreamer and use these to isolate it in between? I feel we shouldn't need to for such short interconnect runs but maybe the shielding from induced noise is worth it?

The main issues that I can see (and that @mdsimon2 ran into) are:

Signal Strength: Voltage drop and noise floor
Signal Integrity: Signal shape/malformed edges
Clock Recovery: Drift from missing edge locks due to poor signal integrity and physical run mismatch drift

I was thinking:

Fixing signal strength: Increase the V+ amplitude with a carrier wave (requires hysteresis curve information to remove on the other end, the TI chips have this included), minimize the cable length to minimize voltage drop, and isolate ground loops to drop the noise floor.
Signal integrity: Re-generate the digital signal and clock before transmitting and/or after receiving before passing on.
Clock Recovery: Poll the received signals at a higher frequency and regenerate the clock based on the expected relation between WordClock and the BitClock. Minimize physical run difference or use a 'learning' bus that can adjust.

What kind of maximum transmission/cable length are we talking about?

 

[Keened]

What kind of maximum transmission/cable length are we talking about?

I'm hoping to keep the total distance of the extracted I2S audio under 1 foot.

0.5 feet if I can manage it (~3" from the blackbox -> HDMI break out -> ~3" to USBStreamer I2S pins)

The HDMI going into the blackbox should hopefully be about 1 foot from the eARC sink device which will in turn be about 1 foot from the HDMI switch which will be fed by arbitrary length cables, but since the eARC sink is regenerating the signal right next to the Blackbox which is also regenerating the signal I don't think everything before it in the chain will matter so long as it's within normal spec.

 

[jrosser]

Yes, the plan is to just use the I2S-over-HDMI port out on this extraction board for multi-channel audio

Are you expecting to get multi-channel PCM extracted from the HDMI data? I'm not sure that is going to happen with the box you linked.

Seems an awful lot of complexity here rather than just connecting a toslink cable between the HDMI extractor and USBStreamer?

What actual problem are you trying to solve?

 

[Keened]

Effectively yah, this previous post in ASR has this particular box as providing 7.1 output capabilities and the one I bought is just the more expensive/capable version of it. Here is the Audiophonics link to the device which goes a bit further into it.

It isn't capable of requesting the high resolution 8 channel LPCM, (so I need an eARC sink in between) but it is capable of converting 8 channels LPCM in bypass mode to I2S over HDMI using the additional physical channels.

The actual problem I'm trying to solve is getting lossless digital audio out from an HDMI stream to feed to an Okto8Pro DAC. This box solves the issue of extracting the digital audio, the issue now is getting it from the low voltage + unbalanced + synchronous I2S into the DAC without errors.

The actual data is already 'encoded' in (L)PCM when it comes out, I could potentially try to capture it and then re-generate it into a S/PDIF compliant signal over EBU/Toslink/whatever but I would have to be able to simultaneously capture each data line, the word clocks, and bit clock, push them to a buffer of some kind, and then clone the word and bit clock onto each channel and sync the respective data lines leading edge and then re-generate. Then the Okto could route the LPCM to a Pi for DSP and the Pi can provide the final corrected digital signal for the DACs.

I'm sure smarter people then I could come up with a hardware answer to this, but from my perspective sometimes it's easier to just bring Mohamed to the Mountain so I'd rather just dump the LPCM data into the Pi from the start via USB which will allow us to do signal processing to fix time misalignments, then feed that to audio DSP, then send that data back out via USB to the Okto (or whatever).

 

[mdsimon2]

That Audiophonics board won't do 7.1 as it only has one I2S data line instead of the necessary four.

Michael

 

[Keened]

That Audiophonics board won't do 7.1 as it only has one I2S data line instead of the necessary four.

Michael

Only when using the pin out, via the HDMI it should do 8-channel (with an ironic? link to psaudio forums)

At least I hope I ordered the right one. If you go through the various posts the description of the item matches the one I got from AliExpress. Audiophonics doesn't mention the channel number but it otherwise seems to match.

Also it looks like it outputs I2S over balanced/LVDS

 

[mdsimon2]

Only when using the pin out, via the HDMI it should do 8-channel (with an ironic? link to psaudio forums)

At least I hope I ordered the right one. If you go through the various posts the description of the item matches the one I got from AliExpress. Audiophonics doesn't mention the channel number but it otherwise seems to match.

Also it looks like it outputs I2S over balanced/LVDS

I see no one in that thread using multichannel I2S or claiming that it will work in an 8 channel system. When I looked in to purchasing a HDMI to I2S board it seemed like there were two designs, a 7.1 and a stereo. I hope it works out as you expect.

As an unrelated question, what is your plan for bridging the HDMI extractor I2S output with the USBStreamer clock domain?

Michael

 

[gy-k]

Sounds like you're planning to design a PCB for this. Approaching it from the input side, If the goal is to feed multi-channel to the Okto8Pro DAC via its AES inputs, signal transformers could provide isolation. Somewhat of a heavyweight solution probably, but an FPGA could be used to convert the I2S inputs into AES. For example the ULX3S board has a HDMI connector with LVDS io. (Alternatively Xilinx has I2S and AES blocks in Vivado, but It seems right now there aren't many simple and affordable boards that are set up for LVDS.)

 

[jrosser]

Only when using the pin out, via the HDMI it should do 8-channel (with an ironic? link to psaudio forums)

I see no evidence of anyone doing multichannel PCM over HDMI connectors in those forums. They all seem to be talking about 2 channel DSD, and on top of that there is the fact that an HDMI cable has four high speed pairs suitable for LVDS. This is enough for one stereo (or encoded multichannel bitstream) signal (MCLK, LRCLK, BCLK, D0). An HDMI cable carrying I2S would never do multichannel LPCM - except for exotic ADAT/TDM type schemes which again there is no evidence of at all.

You want this board from aliexpress to get you MCLK, LRCLK, BCLK, D0, D1, D2, D3. The clocks plus four data pins is 8 channels of PCM.

Connect it to a USBStreamer directly with short jumper wires - before you do any of this figure out how the master clock sync between the two boards is going to work. Other people have mentioned already that it's necessary to hook up the toslink as well to get the correct clocking.

Pay attention to grounding between the boards, power them off the same power supply. Forget all the stuff about needing galvanic isolation and LVDS interconnects. Keep the leads short and observe proper digital design / grounding rather than get caught up in audio forum snake oil "best practices".

If the output of the aliexpress board and the input of the USBStreamer are both truly I2S (there are many, many, variants of the clock/data relationships here...) then it should work. A 4 channel oscilloscope would be invaluable.

Arrange a 1khz tone source and test what you receive through the USBStreamer with REW. Testing the level / distortion / noise floor will help you understand if you have the data bits mapped in the right place.

I've designed complex broadcast A/V gear over the years and all I can advise is sticking to proper digital design and not getting trapped in the confusion in the various audio forums.

Finally - have you thought about what the clock master is for this whole setup of HDMI extractor -> USBStreamer -> Pi -> Okto8?

The audio clock derived from the HDMI source becomes a master pushing data toward the USBStreamer / Pi, but if you connect the Okto8 to the Pi with USB then it will be pulling data from Pi with its own internal clock. This sounds immediatley problematic and needing a sample rate converter somewhere.

 

[mansr]

Sounds like you're planning to design a PCB for this. Approaching it from the input side, If the goal is to feed multi-channel to the Okto8Pro DAC via its AES inputs, signal transformers could provide isolation. Somewhat of a heavyweight solution probably, but an FPGA could be used to convert the I2S inputs into AES. For example the ULX3S board has a HDMI connector with LVDS io. (Alternatively Xilinx has I2S and AES blocks in Vivado, but It seems right now there aren't many simple and affordable boards that are set up for LVDS.)

Why would you use an FPGA when a DIT4192 or similar will do the job?

 

[mdsimon2]

I see no evidence of anyone doing multichannel PCM over HDMI connectors in those forums. They all seem to be talking about 2 channel DSD, and on top of that there is the fact that an HDMI cable has four high speed pairs suitable for LVDS. This is enough for one stereo (or encoded multichannel bitstream) signal (MCLK, LRCLK, BCLK, D0). An HDMI cable carrying I2S would never do multichannel LPCM - except for exotic ADAT/TDM type schemes which again there is no evidence of at all.

You want this board from aliexpress to get you MCLK, LRCLK, BCLK, D0, D1, D2, D3. The clocks plus four data pins is 8 channels of PCM.

Connect it to a USBStreamer directly with short jumper wires - before you do any of this figure out how the master clock sync between the two boards is going to work. Other people have mentioned already that it's necessary to hook up the toslink as well to get the correct clocking.

Pay attention to grounding between the boards, power them off the same power supply. Forget all the stuff about needing galvanic isolation and LVDS interconnects. Keep the leads short and observe proper digital design / grounding rather than get caught up in audio forum snake oil "best practices".

If the output of the aliexpress board and the input of the USBStreamer are both truly I2S (there are many, many, variants of the clock/data relationships here...) then it should work. A 4 channel oscilloscope would be invaluable.

Arrange a 1khz tone source and test what you receive through the USBStreamer with REW. Testing the level / distortion / noise floor will help you understand if you have the data bits mapped in the right place.

I've designed complex broadcast A/V gear over the years and all I can advise is sticking to proper digital design and not getting trapped in the confusion in the various audio forums.

Finally - have you thought about what the clock master is for this whole setup of HDMI extractor -> USBStreamer -> Pi -> Okto8?

The audio clock derived from the HDMI source becomes a master pushing data toward the USBStreamer / Pi, but if you connect the Okto8 to the Pi with USB then it will be pulling data from Pi with its own internal clock. This sounds immediatley problematic and needing a sample rate converter somewhere.

x2 on everything in this post.

I will say that bridging the HDMI extractor clock domain and the Okto clock domain is very easy to do using CamillaDSP rate adjust / resampling.

As an alternative using the Okto AES inputs by converting the HDMI extractor I2S to AES would allow you to use the Okto’s built in buffer / rate adjust functionality and would avoid any resampling.

Michael

 

[gy-k]

Why would you use an FPGA when a DIT4192 or similar will do the job?

I thought the plan was to receive 4x I2S over LVDS and turn that into 4x AES to feed the inputs of the Okto8 DAC.

Though post #17 says the HDMI box might not output multiple I2S channels, and there's a Raspberry Pi mentioned before the DAC. (For signal processing? CamillaDSP?)

If the Raspberry Pi is needed for signal processing, using an FPGA board in place of the USBStreamer could maybe sidestep the clock domain issue:
- feed the I2S over jumper wires from the HDMI board mentioned in #17 into the FPGA
- the Arty A7 board has ethernet, a busy loop on FreeRTOS could read I2S and send as simple PCM streams to the Pi over ethernet
- and receive it back from CamillaDSP on the Pi and write to the AES logic
- I2S, AES logic driven by the same clock, with some delay on the AES output accounting for the processing round trip

But certainly it could take a lot of hours to make this work.