Dump everything you know about HDMI eARC here

[phofman]

The only limiting factor of this setup is inability to use the TV as a content source: you always need an external box with configurable negative audio delay. Fire TV stick works well too.

Authors of eARC were aware of lipsync issues and incorportated detailed latency control into eARC - see section 9.5.3.5 Audio Latency Control of the HDMI 2.1 specs. The transmitter may request a specific latency (0 - 250ms), the receiver should report current latency (which may or may not respect the requested latency). The transmitter then adjusts the audio/video paths to keep lipsync. IMO the picture on page 329 differs from the text description on the following page, but those are details.

IMO it means having access to the RX configuration (to see what latency the transmitter requests and to set what latency the receiver reports) could likely solve the problem.

 

[stigger]

Indeed, having the datasheet for the IT6622FN chip would open lots of interesting possibilities.

 

[phofman]

IIUC that chip has integrated MCU for control. That means it most likely requires a firmware which controls the features. That would require a programming documentation which is extremely unlikely to be released. Especially when HDMI devices require paying licensing fees to Intel. Some manufacturers keep the programming docs private and charge for the firmware and its changes. I asked CMedia for the programming docs to their USB-audio CM6637 (which also has an MCU) and was told that they only make the firmware themselves as a service.

 

[MCH]

IIUC that chip has integrated MCU for control. That means it most likely requires a firmware which controls the features. That would require a programming documentation which is extremely unlikely to be released. Especially when HDMI devices require paying licensing fees to Intel. Some manufacturers keep the programming docs private and charge for the firmware and its changes. I asked CMedia for the programming docs to their USB-audio CM6637 (which also has an MCU) and was told that they only make the firmware themselves as a service.

Lattice did have some eARC evaluation boards. They are discontinued now, no idea what sort of tools were included (they came with a CD) or if they were available to anyone (likely not):

https://www.mouser.lu/ProductDetail/Lattice/CP9437?qs=r5DSvlrkXmLklhOH%2F69i0g%3D%3D

 

[phofman]

Options with full access to any eARC register (and e.g. HDMI input, but without eARC Source) and with full detailed documentation are e.g. https://shop.allnetchina.cn/products/rock5-model-b or https://www.friendlyelec.com/index.php?route=product/product&product_id=292 or https://www.aliexpress.com/item/1005007878976328.html. eARC is not implemented yet https://gitlab.collabora.com/hardwa...-rockchip-3588/-/blob/main/mainline-status.md or https://github.com/Joshua-Riek/ubuntu-rockchip/issues/296 but any option would require custom development anyway. The eARC specs of the config messages are available, IMO it's viable for someone with an eARC transmitter to test and big-enough need No need to plead someone for docs.

 

[stigger]

@phofman The solution with the eARC extractor makes it relatively easy to provide an external clock for the DAC. Do you know if there is any way to sync a DAC to HDMI audio with this board? Perhaps somehow drive the built-in S/PDIF output using the HDMI audio clocks?

I understand that nothing will work out of the box, just trying to understand how risky it is to invest time into it

 

[phofman]

I do not think the internal I2S bitclock from the I2S interface generated by the eARC module can be passed to any of the output pins. However, you can always use a precise clock with your DAC and do quality ASRC between I2S-slave input I2S-slave output in software, e.g. using CamillaDSP. Of course such solution would have a larger latency, but IIUC eARC has quite a large range in latency control (100 - 250ms, IIUC the specs)

just trying to understand how risky it is to invest time into it

Such investment would entail developing a linux kernel driver for the eARC Synopsys IP https://www.synopsys.com/blogs/chip-design/simplify-entertainment-hdmi-earc.html (fortunately documented in the SoC technical datasheet) and configuring the kernel via device tree.

 

[stigger]

From my experience, the problem with using CamillaDSP ASRC is that the resulting latency is slightly different each time, whereas hardware clock syncing allows to keep the latency impressively stable and predictable.

 

[phofman]

Yes, a software chain would never offer the same timing as continuous clock. There is a reason (plus many more) this SW solution is not used in AVRs which deploy dedicated hardware processing chips instead. But it gives a flexibility unattainable by any HW solution. And availability too - anyone can do it now, no hidden secrets necessary, everything is already on the table.

The rate-adjust feature in CDSP is not implemented for a specified I/O latency, but for a specified average fill level of the output device buffer (the target-level param). But it would not be difficult to add such feature. The audio chunks arriving to the Playback thread from the Processing thread (all being OS threads - no guaranteed timing) already carry a timestamp when they were read from the capture device. So the Playback thread on the first chunk arrival, instead of waiting for time corresponding to the target-level, could wait a calculated delay to yield the overall requested latency, including some reasonable target-level - then keeping this target level as is. IMO implementing that would be easier than implementing the eARC driver - let's consider it one step in the overall implementation. Or other bridges like alsaloop (which runs in a single thread) could be used.

IMO a repeatable sub-millisec precision should be attainable with RT kernels which IMO is perfectly OK for lipsync. eARC itself has a latency step of 1 ms.

 

[morethinkingcapacityneede]

Options with full access to any eARC register (and e.g. HDMI input, but without eARC Source) and with full detailed documentation are e.g. https://shop.allnetchina.cn/products/rock5-model-b or https://www.friendlyelec.com/index.php?route=product/product&product_id=292 or https://www.aliexpress.com/item/1005007878976328.html. eARC is not implemented yet https://gitlab.collabora.com/hardwa...-rockchip-3588/-/blob/main/mainline-status.md or https://github.com/Joshua-Riek/ubuntu-rockchip/issues/296 but any option would require custom development anyway. The eARC specs of the config messages are available, IMO it's viable for someone with an eARC transmitter to test and big-enough need No need to plead someone for docs.

As some people have already said, these SBCs have linux support for 8ch audio received via HDMI eARC: https://docs.khadas.com/products/sbc/vim3/applications/earc and https://forum.khadas.com/t/amlogic-kernel-5-4-on-vim3l/15869/3.

I have an AppleTV and Blu-Ray player which can output plain multi-channel PCM, so I don't need Dolby decoding. So for my use case, TV - eARC -> sbc + CamillaDSP -> multi-ch USB DAC, would be a great solution.

Does anyone know a reason why CamillaDSP wouldn't run on a khadas vim3l / vim4 or rock / orange pi ? Any help would be greatly appreciated.

P.S. I also went down the diy eARC IC route, and the lack of documentation is still real.

 

[stigger]

P.S. I also went down the diy eARC IC route, and the lack of documentation is still real.

It does definitely work, though.

 

[morethinkingcapacityneede]

It does definitely work, though.

Sorry, I’m not sure I understand fully what you mean.

Physically making a board with an eARC IC and getting the electrical connections right without a full data sheet is totally doable. If you pick the right IC, you can completely rip off the schematics shown in the various AVR service manuals in which the chip is used.

Then there’s the issue of having access of configuration information and I2C register map, which is the killer. I guess you can harvest an already programmed controller uC or spy on traffic (as already discussed). But no way to customise your behaviour to get the smooth integration with whatever else you want to use your eARC IC with.

All I wanted is to get the 4 I2S buses from eARC into a pi5 for dsp. With the vim3l that works out of the box with the right kernel, and as a bonus: no internal wires from eARC board to pi5, just one SBC. I’ll try to mod the device tree of the vim4 to also enable eARC rx. i just hope the latency is not too long to cause sync issues with the video.

Of course, if you wanted to feed the eARC I2S in some other hardware, the integrated SBC solution above does not work. By the way, I think that’s the big difference between standalone eARC IC and eARC SBC chipsets, the latter are a part of a system and present the audio in an OS. At least that’s what this thread implies: https://support.hifiberry.com/forum/c/product-ideas/10388.

 

[morethinkingcapacityneede]

Sorry, I’m not sure I understand fully what you mean.

Physically making a board with an eARC IC and getting the electrical connections right without a full data sheet is totally doable. If you pick the right IC, you can completely rip off the schematics shown in the various AVR service manuals in which the chip is used.

Then there’s the issue of having access of configuration information and I2C register map, which is the killer. I guess you can harvest an already programmed controller uC or spy on traffic (as already discussed). But no way to customise your behaviour to get the smooth integration with whatever else you want to use your eARC IC with.

All I wanted is to get the 4 I2S buses from eARC into a pi5 for dsp. With the vim3l that works out of the box with the right kernel, and as a bonus: no internal wires from eARC board to pi5, just one SBC. I’ll try to mod the device tree of the vim4 to also enable eARC rx. i just hope the latency is not too long to cause sync issues with the video.

Of course, if you wanted to feed the eARC I2S in some other hardware, the integrated SBC solution above does not work. By the way, I think that’s the big difference between standalone eARC IC and eARC SBC chipsets, the latter are a part of a system and present the audio in an OS. At least that’s what this thread implies: https://support.hifiberry.com/forum/c/product-ideas/10388.

If the mini dsp HT series could auto switch digital inputs, SPDIF, TOSLIMK, eARC, I would just get that.

But for £200, I thought a SBC can do the DSP, and the auto switch can be done in hardware (not without eARC IC) or software (I think camilladsp can do this with some customisations )

 

[stigger]

Sorry, I’m not sure I understand fully what you mean.

Well, I consider getting an eARC extractor and soldering to the I2S lanes between the chips to be DIY as well. It's not an ideal solution, but does work quite well for me.

 

[morethinkingcapacityneede]

Got you thanks

 

[ezzieyguywuf]

All I wanted is to get the 4 I2S buses from eARC

Did you ever figure out a way to do this? I've been noodling around with the idea of doing a lil eARC project just for fun and science, but as others have pointed out in this thread it's incredibly difficult to come by ICs let alone data sheets to even get started.

 

[morethinkingcapacityneede]

Did you ever figure out a way to do this? I've been noodling around with the idea of doing a lil eARC project just for fun and science, but as others have pointed out in this thread it's incredibly difficult to come by ICs let alone data sheets to even get started.

Hi. Welcome to ASR!

For the IC route, you can buy the Sil9437 https://www.ebay.co.uk/itm/335611153317 and https://www.aliexpress.com/item/1005008933575396.html, but the problem is the real lack of a datasheet as you said. For the hardware, less of a big deal, example schematics are available in the service manuals of AVRs which use this chip, e.g.: https://www.audiocircuit.dk/downloads/denon/Denon-AVRX3400H-avr-sm.pdf. Since posting, I have found some open source drivers for the Sil9437: https://github.com/flaviut/sii9437, which will get you a long way to getting the chip up and running. Also, the NUC uses that chip, I believe, so that's another potential source of information. If I were to pursue this route further, I'd port the code to a uC or an FPGA, and start the long-ish process of writing the application logic for the IC.

I just need ARC/eARC audio available in Linux, so for me, the I2S was a means to an end. As someone mentioned previously, there are several SoCs (and SBCs implementing them), which have ARC / eARC support built-in, so I started looking into those. I looked at three different SoCs families, and here's what I've got so far.

Rockchip RK3588
Used in the Orange Pi 5 and Raxda 5B SBC (among others). The ARC / eARC harware support is there on the SBCs (i.e. pins connected to the SoC), but Linux ARC / eARC driver support is lacking. It looks they support CEC though, which is a requirement for ARC but not eARC AFAIK (ARC link negotiation is over CEC, but not for eARC). There is some professional efforts to develop the drivers for the SoC (already discussed previously in the thread), https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux, but not sure if or when eARC support will be added.

Amlogic A311D2 / S905D3
Used in the Khadas VIM4 / VIM3L, again hardware support is there but driver support lacking or patchy. The VIM3L supports eARC (not ARC I think): https://docs.khadas.com/products/sbc/vim3/applications/earc, and there's evidence of other people having it work: https://forum.khadas.com/t/amlogic-kernel-5-4-on-vim3l/15869. For the VIM4, it wouldn't work out of the box, but enabling eARC support in the Linux device tree shouldn't be too bad. For ARC, you'd need CEC, and that's more complicated on these SBCs, they only support CEC on Android, presumably because usually these things run TVs.

NXP i.MX 8M Plus
SoC is available on a dev board directly from NXP: https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX8MPLUS. Documentation suggests ARC / eARC (and CEC) is supported out the box. This seems to be confirmed by this forum post which has someone having ARC / eARC working: https://community.nxp.com/t5/i-MX-Processors/IMX8MP-ARC-lt-gt-eARC-transition/m-p/1849952.

I've ordered the NXP board and will try it out. I only have an ARC source at the moment, so I won't be able to test eARC.

For now, I'm not looking into putting the IC onto a PCB further.

My ultimately project would be a board with HDMI ARC / eARC in (using Sil9437) as well as several SPDIF and TOSLINK inputs, all going into a powerful FPGA SoC. Then you can do your streaming on the processor side, and DSP in the FPGA, and put this into a box, with a quality OEM 8ch DAC module.

For now though I'd be happy if the NXP works nicely with CamillaDSP, and a USB DAC. I think this will work, but the question is, how much effort will it be to get it work reliably and smoothly with sources going on / off, being plugged / unplugged, auto switch, TV remote volume control, etc..

 

[MCH]

Hi. Welcome to ASR!

For the IC route, you can buy the Sil9437 https://www.ebay.co.uk/itm/335611153317 and https://www.aliexpress.com/item/1005008933575396.html, but the problem is the real lack of a datasheet as you said. For the hardware, less of a big deal, example schematics are available in the service manuals of AVRs which use this chip, e.g.: https://www.audiocircuit.dk/downloads/denon/Denon-AVRX3400H-avr-sm.pdf. Since posting, I have found some open source drivers for the Sil9437: https://github.com/flaviut/sii9437, which will get you a long way to getting the chip up and running. Also, the NUC uses that chip, I believe, so that's another potential source of information. If I were to pursue this route further, I'd port the code to a uC or an FPGA, and start the long-ish process of writing the application logic for the IC.

I just need ARC/eARC audio available in Linux, so for me, the I2S was a means to an end. As someone mentioned previously, there are several SoCs (and SBCs implementing them), which have ARC / eARC support built-in, so I started looking into those. I looked at three different SoCs families, and here's what I've got so far.

Rockchip RK3588
Used in the Orange Pi 5 and Raxda 5B SBC (among others). The ARC / eARC harware support is there on the SBCs (i.e. pins connected to the SoC), but Linux ARC / eARC driver support is lacking. It looks they support CEC though, which is a requirement for ARC but not eARC AFAIK (ARC link negotiation is over CEC, but not for eARC). There is some professional efforts to develop the drivers for the SoC (already discussed previously in the thread), https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux, but not sure if or when eARC support will be added.

Amlogic A311D2 / S905D3
Used in the Khadas VIM4 / VIM3L, again hardware support is there but driver support lacking or patchy. The VIM3L supports eARC (not ARC I think): https://docs.khadas.com/products/sbc/vim3/applications/earc, and there's evidence of other people having it work: https://forum.khadas.com/t/amlogic-kernel-5-4-on-vim3l/15869. For the VIM4, it wouldn't work out of the box, but enabling eARC support in the Linux device tree shouldn't be too bad. For ARC, you'd need CEC, and that's more complicated on these SBCs, they only support CEC on Android, presumably because usually these things run TVs.

NXP i.MX 8M Plus
SoC is available on a dev board directly from NXP: https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX8MPLUS. Documentation suggests ARC / eARC (and CEC) is supported out the box. This seems to be confirmed by this forum post which has someone having ARC / eARC working: https://community.nxp.com/t5/i-MX-Processors/IMX8MP-ARC-lt-gt-eARC-transition/m-p/1849952.

I've ordered the NXP board and will try it out. I only have an ARC source at the moment, so I won't be able to test eARC.

For now, I'm not looking into putting the IC onto a PCB further.

My ultimately project would be a board with HDMI ARC / eARC in (using Sil9437) as well as several SPDIF and TOSLINK inputs, all going into a powerful FPGA SoC. Then you can do your streaming on the processor side, and DSP in the FPGA, and put this into a box, with a quality OEM 8ch DAC module.

For now though I'd be happy if the NXP works nicely with CamillaDSP, and a USB DAC. I think this will work, but the question is, how much effort will it be to get it work reliably and smoothly with sources going on / off, being plugged / unplugged, auto switch, TV remote volume control, etc..

Awesome overview, thanks for putting it together and sharing. And please keep us posted on your progress with the nxp eval board, the ones I was aware of from lattice were several hundred euros if I remember correctly.

 

[ezzieyguywuf]

Hi. Welcome to ASR!

Wow, thank you for such a great and detailed response!

My idea was to essentially build my own miniDSP flex HT, just for the fun of it/for learning. I like the idea of tinkering with the PCM signal and communicating with the host device via CEC for like volume control and stuff. I was thinking of using something like an ADAU1797A do do the dsp once I get the PCM out of the HDMI, but really all this is new to me so . It even seems like one could use e.g. SSM-2125 to decode the dolby surround stream if they wanted, which may also be fun to tinker with.

From the research I've done, the CEC should be relatively straightforward to "bit bang" as it's a relatively slow communication on a single wire. the ARC/eARC stuff is a different story, and while I think it'd be fun to try to implement those too the price of entry for the HDMI spec is just too high.

I'll certainly take a look at the SMCs you've listed, and I'm interested to hear your experience with the NXP

 

[ezzieyguywuf]

Woah, looking at the datasheet for the nxp i.MX 8M Plus (I had to make an account to access it so I won't screenshot or quote it directly) on page 6159 it certainly seems like this handles eARC input, I think I may pick one up myself! Unfortunately still a bit price e.g. $126 on mouser but still a fraction of the cost of the miniDSP and seems like a fun platform for learning and science. I'd still rather be able to just do the eARC with e.g. one of those Sil9437, but I suppose I'll just have to abandon that dream.