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.