Dump everything you know about HDMI eARC here

[MCH]

Hi,
As a tangent from another project i recently became interested about HDMI eARC, to the point that I went and read everything about it I could find in the internet. It took me about 30 minutes.
Not satisfied, i bought from Aliexpress the cheapest eARC audio extractor that I could find. It is one of those boxes that takes eARC and outputs audio over HDMI. The insides of the device turned out to be more interesting than I initially thought for the price:
The device has two ITE ICs. The smaller one, more modern and capable, receives the eARC signal and transfers the audio via multichannel i2s (4 data lines+clocks) to the bigger IC, that generates the "audio over HDMI" output. Fortunately, there is a short datasheet available for the output IC (IT66121FN) that confirms that those pins that receive the data from the first IC are indeed i2s inputs. ( https://www.infinite-electronic.pt/datasheet/e0-103030034.pdf )

Here i need to stop and say that both ICs are controlled by a MCU and it is well beyond my capabilities and interest to try to figure out what is going on there and how the thing works. I can imagine there are EDID handshakes etc. happening when you connect sources and sinks. Just check the amount of exposed headers and test points, the extractor is more complex than it seems.

Anyways, what called my attention is that both ICs are capable of a few audio formats, including DTS-HD and Dolby TrueHD in between others. And seems that it is possible to transmit those formats, encoded, through the i2s data lines.
Now my question or suggestion is. Having access to those i2s data lines, is there a way to capture and decode the audio to LPCM? Does it make it any easier to capture the data in this format vs embedded in the HDMI video signal? has this been done before?

There is a bit of discussion in the Analog Devices forum, in between other posts, here:

How HBR audio bitstream embedded to I2S output interface in parallel mode when audio input source is Dolby TrueHD and DTS-HD Master Audio? - Q&A - Video - EngineerZone

Dir Sir. We have questions about how ADV7622 put HBR audio bitstream to I2S output interface in paralle mode(4 data lines). Is there any format diff. output from

ez.analog.com

 

[voodooless]

Having access to those i2s data lines, is there a way to capture and decode the audio to LPCM? Does it make it any easier to capture the data in this format vs embedded in the HDMI video signal? has this been done before?

Maybe..? You’ll need something to capture the I2s lines, recombine the data to the original bitstream and then have access to the licensed decoders. There are some free implementations of True HD and Atmos out there, but it’s going to be another integration hell. Nevermind the delay you’ll have when dealing with PC-like hardware (which you’ll need for the codecs). If MCUs are a bridge too far, this is will be as well.

 

[somebodyelse]

What is the aim here? Extracting 7.1 PCM? Some SBCs have HDMI input with eARC capability, at least nominally. Documentation on getting it working is patchy though. See https://forum.khadas.com/t/amlogic-kernel-5-4-on-vim3l/15869/3 for example of announcing 7.1 PCM support via alsa mixer setting. http://docs.khadas.com/products/sbc/vim3/applications/earc doesn't cover that bit. I haven't found even that much for RK3588 based boards like the Orange Pi 5 Plus.

 

[MCH]

What is the aim here? Extracting 7.1 PCM? Some SBCs have HDMI input with eARC capability, at least nominally. Documentation on getting it working is patchy though. See https://forum.khadas.com/t/amlogic-kernel-5-4-on-vim3l/15869/3 for example of announcing 7.1 PCM support via alsa mixer setting. http://docs.khadas.com/products/sbc/vim3/applications/earc doesn't cover that bit. I haven't found even that much for RK3588 based boards like the Orange Pi 5 Plus.

To extract 7.1PCM i think the best is to use the extractor as it is and just plug a HDMI to i2s board at the output.
If for some reason one wants to extract directly the i2s from this board (the hdmi to i2s boards don't come as cheap as this one) I think there are chances it works desoldering the resistors and soldering some wires. All this if the receiver IC does not complain about losing the input signal it expects.
My question was more about if there was a DIY feasible way to extract and decode the proprietary formats while they are being transmitted through i2s, hoping this was a more decode friendly format. According to Voodooless, it doesn't seem to facilitate things much.

 

[phofman]

IMO it's just a non-audio stream, like non-audio SPDIF, only more two-channel pairs. A properly configured ffmpeg or gstreamer should decode TrueHD to PCM. I have not seen ffmpeg being able to decode the Atmos spatial objects streams but the core TrueHD stream should work.

 

[MCH]

IMO it's just a non-audio stream, like non-audio SPDIF, only more two-channel pairs. A properly configured ffmpeg or gstreamer should decode TrueHD to PCM. I have not seen ffmpeg being able to decode the Atmos spatial objects streams but the core TrueHD stream should work.

I guess that is the case. IEC 60958-1 standard that applies to eARC says:

"When used for other purposes, the interface is able to carry audio data coded other than as linear PCM coded audio samples. Provision is also made to allow the interface to carry data related to computer software, multimedia technologies, or signals coded using non linear PCM. The format specification for these applications is not part of this document."

What I read as "they can do as they please"

 

[phofman]

Viewing the captured stream with any hexaviewer should tell if the stream still contains the IEC958 envelope. If so, the envelope could be removed by capturing through the iec958 plugin. The resulting bitstream may be recognized by ffmpeg or gstreamer if properly configured.

Making the simple cases (ac3, dts) work first and then proceeding with the newer formats (trueHD, Atmos + TrueHD) could be the way forward. Dolby released gstreamer decoding plugins https://github.com/DolbyLaboratories/gst-home-audio

 

[MCH]

Fascinating deep dive into eARC! Who knew a cheap extractor would hold such interesting insides? Thanks for sharing the details - particularly the ITE chip combo and i2s interface. Love seeing people explore the tech behind everyday devices. Looking forward to any further discoveries you make!

Thanks. The problem is that unfortunately any information HDMI related is not available to the DIY community. If you ask any of these companies for a simple datasheet, they will ask you for HDCP membership first :-( But sometimes you can find info enough to "transplant" one of those ICs and use them in your projects. Does not seem to be the case here unfortunately.

 

[phofman]

IMO the audio HDMI coding info is available online (not officially, but leaked PDFs). IIUC the actual formatting of the Atmos stream is independent of the HDMI transfer (standard non-audio stream) and needs to be handled by the decoding software, no matter whether the stream came over HDMI or from a file.

E.g. Rockchip SoCs have rather detailed datasheets regarding their HDMI receiver/transmitter including some eARC - https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet/tree/master

 

[nullpointerninja]

Came across this page: http://docs.khadas.com/products/sbc/vim3/applications/earc. If I read correctly, this means we could capture an eARC stream and either write to a file or process as necessary.

The interesting bits are at the bottom:

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: AMLAUGESOUND [AML-AUGESOUND], device 0: TDM-B-dummy-alsaPORT-i2s multicodec-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 1: TDM-A-dummy-alsaPORT-pcm multicodec-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 2: TDM-C-dummy dummy-2 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 3: PDM-dummy-alsaPORT-pdm dummy-3 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 4: SPDIF-dummy-alsaPORT-spdif dummy-4 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 6: EARC/ARC-dummy-alsaPORT-earc dummy-6 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLAUGESOUND [AML-AUGESOUND], device 7: LOOPBACK-A-dummy-alsaPORT-loopback dummy-7 []
Subdevices: 1/1
Subdevice #0: subdevice #0

The card 0, device 6 device is the eARC device. You can record audio with the command below:

arecord -D hw:0,6 -f S16_LE -c 2 -r 48000 /tmp/out.wav

 

[MCH]

Came across this page: http://docs.khadas.com/products/sbc/vim3/applications/earc. If I read correctly, this means we could capture an eARC stream and either write to a file or process as necessary.

The interesting bits are at the bottom:


The card 0, device 6 device is the eARC device. You can record audio with the command below:

I wonder about the multichannel capabilities, the example is typical arc 2 channels 48khz 16 bit and a fast search couldn't find anything else than this user saying that only stereo is possible and asking when multichannel will be available:

Any plans for mult-channel DAC or digital out?

VIM3L and VIM4 support hdmi eARC which makes them a great candidate to get home theater sound from the TV. But as of now there isn’t much you can do except output as stereo (with the amazing tone) or use an USB output for multi-channel home theater (either digital out or to analog). Are there...

forum.khadas.com

If multichannel works, it would be a great device

 

[somebodyelse]

See https://forum.khadas.com/t/amlogic-kernel-5-4-on-vim3l/15869/3 for a user posting an example for 7.1 support, unfortunately not included in the Khadas docs. It makes me wonder what other details may not have been mentioned.

 

[phofman]

IIUC that takes running a custom (old patched) android kernel from github https://github.com/lukefor/linux/tree/vim3l_earc

 

[somebodyelse]

That's my understanding too. From what little I've found I get the impression eARC in linux doesn't have a standardised interface yet. Or Android for that matter. Each manufacturer is doing it their own way.

Another example of people trying to work out how to get it to work on another manufacturer kernel:
https://community.nxp.com/t5/i-MX-Processors/IMX8MP-ARC-lt-gt-eARC-transition/m-p/1849952

 

[phofman]

I do not think there will be any standardization for such a niche technology. The SoC-specific driver creates an alsa device and defines some alsa controls for settings. Every SoC will have it differently.

As of digital-format standardization - the only one I know about is SPDIF with the IEC958 control names https://www.kernel.org/doc/html/v4.13/sound/designs/control-names.html#iec958-s-pdif-interface - e.g. https://github.com/alsa-project/alsa-lib/blob/master/src/conf/cards/HDA-Intel.conf#L88-L136 . Actually very few drivers set these values anyway, eventhough players use them (e.g. mplayer https://github.com/philipl/mplayer/...18544154f7483e3182/libao2/ao_alsa.c#L297-L327 or mpv https://github.com/mpv-player/mpv/b...3c31bfbcd435d12/audio/out/ao_alsa.c#L573-L577 )