Dump everything you know about HDMI eARC here

[stigger]

So, I got a rewritable dummy HDMI plug, but to my surprise it did not affect the behavior. I started experimenting further and here is what I've found out:

- Neither the presence of the plug nor the difference in EDID configuration seem to affect anything, at least for PCM audio. For example, I tried to allow only 5.1 PCM in EDID, but the extractor would still switch to 7.1. This is a bit unexpected, because the MCU definitely reads out the sink EDID from the IT66121 chip. Not sure what it does with it.
- It looks like my TV (Sony A95L) always downmixes audio to 2.0 when configured to output PCM. The only time I saw a multichannel PCM output was when I configured TV to passthrough audio, and the media player to output PCM to the TV
- One of my goals was to output multichannel audio from the TV apps. So far it looks like the only way to achieve that (at least with my specific TV) is to passthrough the audio all the way to RPi and try to decode it there, if that's even possible.

 

[stigger]

Received the RPi 5 and tried actually recording the I2S input coming from the extractor. No surprises here: was able to capture PCM just fine. The passthrough streams are there as well, so far I only tried capturing with arecord, but the resulting data looks sane, restoring the original stream and decoding it seems doable.

 

[stigger]

Small update: everything works quite well with the multichannel PCM audio. The biggest problem that I've encountered is that I use the matching the framerate and HDR mode on my mediaplayer, so whenever they change and trigger an HDMI handshake, the clock momentarily signal disappears from the extractor and the MOTU Ultralite Mk5 takes forever to lock back unto it. This is quite annoying, so I'm even considering returning the Ultralite and switching back to M4: the latency is not as stable, of course, but Camilla DSP mostly manages to keep it within the defined limits.

Another unfortunate discovery was related to the audio produced by my TV: in some cases the audio is wrapped into a MAT transport format which is, of course, proprietary and I couldn't find any information on how to strip that particular version of MAT that is used by my TV. I haven't tried to reverse-engineer it yet, might attempt at some point in the future. The regular E-AC3/TrueHD/DTS-HD MA codecs are not so difficult to decode using ffmpeg, I've successfully done that from the I2S captures performed on the RPi. It should be possible to write an ALSA plugin that handles decoding on the fly, but I have not attempted to do that either.

 

[MCH]

Small update: everything works quite well with the multichannel PCM audio. The biggest problem that I've encountered is that I use the matching the framerate and HDR mode on my mediaplayer, so whenever they change and trigger an HDMI handshake, the clock momentarily signal disappears from the extractor and the MOTU Ultralite Mk5 takes forever to lock back unto it. This is quite annoying, so I'm even considering returning the Ultralite and switching back to M4: the latency is not as stable, of course, but Camilla DSP mostly manages to keep it within the defined limits.

Another unfortunate discovery was related to the audio produced by my TV: in some cases the audio is wrapped into a MAT transport format which is, of course, proprietary and I couldn't find any information on how to strip that particular version of MAT that is used by my TV. I haven't tried to reverse-engineer it yet, might attempt at some point in the future. The regular E-AC3/TrueHD/DTS-HD MA codecs are not so difficult to decode using ffmpeg, I've successfully done that from the I2S captures performed on the RPi. It should be possible to write an ALSA plugin that handles decoding on the fly, but I have not attempted to do that either.

hey @stigger , glad you made it work. Would you mind writing a brief description of what you did? i understand that you taped the i2s pins of the earc extractor to a raspberry pi and you use a HDMI plug to fool the extractor. Is that correct? did you have to use the UART port? also any details on how you decoded the AC3, DTS etc would be great. Thanks!

 

[stigger]

hey @stigger , glad you made it work. Would you mind writing a brief description of what you did? i understand that you taped the i2s pins of the earc extractor to a raspberry pi and you use a HDMI plug to fool the extractor. Is that correct? did you have to use the UART port? also any details on how you decoded the AC3, DTS etc would be great. Thanks!

It turned out that the HDMI plug is not needed, the extractor seems to ignore it and always advertises itself as a 7.1 system that accepts all possible codecs. I've configured the TV to passthrough the audio, and my media player (Kodi on Ugoos AM6B+) downmixes everything to 3.1 and outputs multichannel PCM. So all that's left to do is just to get those I2S lanes to the RPi and that's it: configure the capture device to use `hw:GenericStereoAu,1,0`, `S32LE` and 8 channels, and the multichannel PCM is going to "just work". Never had any issues so far with the channel swapping or unexpected audible noise.

Non-PCM streams are wrapped into the IEC598 protocol. ffmpeg can decode it out of the box for some of the codecs (ac3, aac, eac3) using the `spdif` demuxer, but not for DTS-HD or TrueHD. Supporting them is not too difficult though, I managed to do that and it worked fine for the passthrough streams produced by Kodi. I might try to contribute that to upstream at some point, but the practical applicability is not clear yet: with Kodi I don't really need passthrough codecs, because it can output multichannel PCM. My TV, however, can itself produce only stereo PCM, and when passing through TrueHD or multichannel PCM from internal applications, it uses the variant of Dolby MAT which I haven't been able to decode yet.

 

[MCH]

It turned out that the HDMI plug is not needed, the extractor seems to ignore it and always advertises itself as a 7.1 system that accepts all possible codecs. I've configured the TV to passthrough the audio, and my media player (Kodi on Ugoos AM6B+) downmixes everything to 3.1 and outputs multichannel PCM. So all that's left to do is just to get those I2S lanes to the RPi and that's it: configure the capture device to use `hw:GenericStereoAu,1,0`, `S32LE` and 8 channels, and the multichannel PCM is going to "just work". Never had any issues so far with the channel swapping or unexpected audible noise.

Non-PCM streams are wrapped into the IEC598 protocol. ffmpeg can decode it out of the box for some of the codecs (ac3, aac, eac3) using the `spdif` demuxer, but not for DTS-HD or TrueHD. Supporting them is not too difficult though, I managed to do that and it worked fine for the passthrough streams produced by Kodi. I might try to contribute that to upstream at some point, but the practical applicability is not clear yet: with Kodi I don't really need passthrough codecs, because it can output multichannel PCM. My TV, however, can itself produce only stereo PCM, and when passing through TrueHD or multichannel PCM from internal applications, it uses the variant of Dolby MAT which I haven't been able to decode yet.

Ah ok, thanks.
I couldn't find anything on the decoding part (I have no idea about these things, I would need to find a detailed tutorial) so I ended up with a dts decoder board, that so far is working, but is ARC, not eARC.
One last question. When you take the i2s signal, are you disconnecting the tracks to the second chip or you leave everything as is?
Thanks a lot.

 

[stigger]

No, not disconnecting anything, I even left the resistors in place and simply soldered the wires to them.

 

[somebodyelse]

It looks like support for the RK3588 HDMI input is heading into the upstream kernel:

The media subsystem updates also include support for the Synopsys DesignWare HDMI RX controller for receiving HDMI input. The Synopsys DesignWare HDMI RX is used by the Rockchip RK3588 SoC and other hardware. With the Synopsys DesignWare HDMI RX there is support for HDMI 1.4b and HDMI 2.0 input up to 4K@60, HDMI CEC support, a variety of pixel formats, and more.

https://www.phoronix.com/news/Linux-6.15-Media-Subsystem

 

[phofman]

It looks like support for the RK3588 HDMI input is heading into the upstream kernel:

https://www.phoronix.com/news/Linux-6.15-Media-Subsystem

Tracked by Collabora (which IMO was contracted by Rockchip to mainline the support) https://gitlab.collabora.com/hardwa...-rockchip-3588/-/blob/main/mainline-status.md

The HDMI RX Audio is still TODO - we would have to look at the RK3588 datasheet to see what parts are missing. Probably something specific to configuration of HDMI RX as the physical audio output from the HDMI RX block is internal I2S for which the I2S receiver is already supported.

 

[marX]

Sorry folks, many of the stuff you guys discussed is all Greek to me! I have a weird question. How to get the miniDSP Flex HT 8 working from a HDMI PCM audio source like an Apple TV if the monitor used is a PC gaming one without any ARC features? Would - HDMI Arc Splitter>HDMI output >HDMI splitter > HDMI dummy plug with ARC edid (if possible?) and then connecting the Arc output from the Arc splitter to the miniDSP work? Is there any simpler way?

 

[MCH]

Sorry folks, many of the stuff you guys discussed is all Greek to me! I have a weird question. How to get the miniDSP Flex HT 8 working from a HDMI PCM audio source like an Apple TV if the monitor used is a PC gaming one without any ARC features? Would - HDMI Arc Splitter>HDMI output >HDMI splitter > HDMI dummy plug with ARC edid (if possible?) and then connecting the Arc output from the Arc splitter to the miniDSP work? Is there any simpler way?

hm, i am sorry i dont have an answer for you but ARC will only carry stereo, or compressed 5.1 that i think the minidsp cannot decode.
I wonder, maybe others can confirm, if a simple HDMI splitter at the output of the apple TV will allow you to connect your monitor for video and your minidsp for audio...

 

[phofman]

IIUC the HDMI port on miniDSP Flex HT is output with eARC. That means it accepts audio via the "fast SPDIF" line of eARC, unlike HDMI input which accepts standard HDMI audio transmitted in blanking periods of the video signal.

 

[marX]

hm, i am sorry i dont have an answer for you but ARC will only carry stereo, or compressed 5.1 that i think the minidsp cannot decode.
I wonder, maybe others can confirm, if a simple HDMI splitter at the output of the apple TV will allow you to connect your monitor for video and your minidsp for audio...

There is a solution - HD fury arcana. But it's costly and HDMI earc has different channel layout compared to USB audio.

Splitting the HDMI does not work as far as I know.

 

[djtwxj]

Small update: everything works quite well with the multichannel PCM audio. The biggest problem that I've encountered is that I use the matching the framerate and HDR mode on my mediaplayer, so whenever they change and trigger an HDMI handshake, the clock momentarily signal disappears from the extractor and the MOTU Ultralite Mk5 takes forever to lock back unto it. This is quite annoying, so I'm even considering returning the Ultralite and switching back to M4: the latency is not as stable, of course, but Camilla DSP mostly manages to keep it within the defined limits.

Another unfortunate discovery was related to the audio produced by my TV: in some cases the audio is wrapped into a MAT transport format which is, of course, proprietary and I couldn't find any information on how to strip that particular version of MAT that is used by my TV. I haven't tried to reverse-engineer it yet, might attempt at some point in the future. The regular E-AC3/TrueHD/DTS-HD MA codecs are not so difficult to decode using ffmpeg, I've successfully done that from the I2S captures performed on the RPi. It should be possible to write an ALSA plugin that handles decoding on the fly, but I have not attempted to do that either.

Great news
Hi Stigger, any update of capture hdmi in dolby atmos ? if u have record samples of dolby atmos will u share it for me?

 

[stigger]

Atmos metadata is the whole other thing, that is kind of separate from just decoding the audio. I'm not aware of any solution that would allow to decode the object metadata, ffmpeg certainly can't do that.

 

[Fahzz]

I run my music (stream and local tracks) from a mini PC. I'm currently using an outboard DAC with RCA outputs in to a Denon 4800 AVR. The PC has HDMI outputs and the AVR has HDMI inputs. Can I connect the PC to the AVR by HDMI for listening to music instead?

 

[somebodyelse]

Atmos metadata is the whole other thing, that is kind of separate from just decoding the audio. I'm not aware of any solution that would allow to decode the object metadata, ffmpeg certainly can't do that.

Cavern seems to render at least some subsets of Atmos object encodings to arbitrary speaker layouts. More details in the other thread:
https://www.audiosciencereview.com/forum/index.php?threads/atmos-finally-decoded-in-pc-mac.32351/

 

[djtwxj]

Cavern can only decode ddp atmos

 

[djtwxj]

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 )

View attachment 379282

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

Hi,
which module of this product? do u have the link?

thanks

 

[MCH]

Hi,
The AliExpress shop where I bought mine does not sell it anymore, but this one is identical to mine:

https://a.aliexpress.com/_EwBJZQi