• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

I2S isolation

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
4,685
Likes
10,703
Location
Hampshire
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.
So use a suitable LVDS to LVCMOS converter connected to 4x DIT4192.
 
OP
K

Keened

Senior Member
Forum Donor
Joined
Nov 2, 2021
Messages
329
Likes
219
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
Fingers crossed, it had the same title description as the original linked one from ASR and before it disappeared from ebay I thought I had remembered it in a similar box.

I was thinking run the USBStreamer at maximum sample rate and loop the clock so it outputs from the USBStreamer to a cheap FIFO reclocker (would need a few of those all feeding from the same USBSteamer clock), use a more expensive active reclocker chip that can accept an external clock (I saw one somewhere in my searches in the past few days), or see if I can somehow just pull the raw pulse data and decode inside the Pi.

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.

I was referring to the posts here and such where they talk about the 5.1 mode listed, but with so many dead links it's quite possible I've ordered the wrong one.

I don't see why HDMI wouldn't be able to carry 4x TDM channels, you'd have to use the DDC twisted pair for the clock and repurpose the official clock channel for a TDM but for a short run it should be fine since you're still double shielded

iu


That said...I originally thought it was single ended connections coming out of this so I thought it was just using HDMI as a common shielded consumer cable with sufficient number of connectors. Which made sense to me because almost no one owns shielded ethernet at home and buying pre-terminated HDMI cables in a variety of lengths is pretty easy. Now, after spending money and time, having discovered it's LVDS (both in the general 'wiring standard' and usage) I'm not quite sure where to go except forward so...

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.

In general, I'd like to avoid working towards an AES based solution since the only reasonably priced solution for that at the moment is using the Okto; instead I'd like to try for a more generalized USB based solution because once you have the signal fully in the software domain you can do just about anything to it and move it around as you need. Also it seems like it's just as much of a pain to convert multi-channel I2S to AES.

I haven't finished reading all the posts on here yet (unfortunately I can't spend as much time as I would like researching and re-squaring my understanding this subject this weekend), but I'll continue to monitor posts while I wait for the parts/scope/etc to arrive.

Thank you everyone for your help on this! I am going to look into picking up a 4 channel oscillator now to do proper debugging and design. If anyone has a good used one hanging around DM me and lets see if it makes sense for me to purchase it from you instead.
 

gy-k

Member
Joined
Oct 25, 2021
Messages
39
Likes
22
So use a suitable LVDS to LVCMOS converter connected to 4x DIT4192.
Could be 5x dual LVDS receivers and 4x DIT4192 for example. I think creating a board for that is going to be more involved than buffering AES lines from the FPGA. At Mouser 4x DIT4192 chips cost 26EUR, the smallest ULX3S costs 105EUR, ex VAT though. (It has a HDMI connector on board. I wonder what could it do with FIR. The Arty board with ethernet is around 120EUR.)
 
Last edited:
OP
K

Keened

Senior Member
Forum Donor
Joined
Nov 2, 2021
Messages
329
Likes
219
Could be 5x dual LVDS receivers and 4x DIT4192 for example. I think creating a board for that is going to be more involved than buffering AES lines from the FPGA. At Mouser 4x DIT4192 chips cost 26EUR, the smallest ULX3S costs 105EUR, ex VAT though. (It has a HDMI connector on board. I wonder what could it do with FIR. The Arty board with ethernet is around 120EUR.)

I'm not saying cost is no object, but when we're talking about (on average) multi-thousand dollar alternatives ~$200 is still well within budget. If we can knock the implementation down a magnitude we'll open the field up to *most* people who have multi-channel audio setups. If the VanityPro was $500 I wouldn't even be looking into this.

But after thinking about it last night it might make more sense to use ethernet as a transportation layer. I2S, even if you capture it perfectly, is difficult to transport long distances and has to run realtime/doesn't have error correction/needs to be repackaged if buffered. HDMI already has the data encoded in LPCM in the Data Island with a clock recovery scheme baked in. Maybe it makes more sense to just build an appropriately sized DMA buffer that blindly dumps the frame data when it detects the end of a Data Island. Then you can just split the bits as appropriate to recover the data and repackage them into ethernet frames for UDP streaming or go full AES67.

But at that point it's like why don't I just use a USB3.0 HDMI capture card and just run the result through an ffmpg to extract the audio...
 
Top Bottom