Making a HDMI audio type detector - Page 1
Forum section: electronics / projects

author: teddyng
author_rank: Newbie
timestamp: November 12, 2019, 01:04:28 pm
content: I want to make a device that goes inline on a HDMI to detech what type of audio it is (PCM, dolby digital, dolby digital+...) which I know is possible as you can normally see it on a tv or amplifier but not sure how to approach it? Can anyone help me out with some ideas?

author: soldar
author_rank: Super Contributor
timestamp: November 12, 2019, 04:29:18 pm
content: Quote from: teddyng on November 12, 2019, 01:04:28 pmAs all HDMI signals are digitally encoded I assume examining the contents of the digital streams will say somewhere what the frame or packet contains so it can be interpreted and decoded.Also, different versions of HDMI have different capabilities so I suppose the version is also specified in the transmitted data.In any case, you will need to analyze the data stream and interpret it using the HDMI standard.

author: Yansi
author_rank: Super Contributor
timestamp: November 12, 2019, 04:38:45 pm
content: HDMI sink signals it's supported formats to the HDMI source using the DDC/EDID, using SAD (short audio descriptors).Can somebody fill in my gap in knowledge, how the HDMI sink then determines in what format is the audio data received?(That will also probably be the partial answer for the OP how to grasp the problem)Usually, HDMI receiver codec just provides a multichannel raw audio data (4x I2S or TDM), that then gets interpreted by the decoder. Question is, how the decoder decides, whether it is receiving raw LPCM, or compressed garbage?Thx, Y.

author: soldar
author_rank: Super Contributor
timestamp: November 12, 2019, 05:16:29 pm
content: I see in Wikipedia that there are several audio formats which can be optionally supported. I am guessing there is a protocol between sender and receiver where the sender lists its capabilities and the receiver chooses what format it prefers.

author: Yansi
author_rank: Super Contributor
timestamp: November 12, 2019, 06:39:01 pm
content: There is no bidirectional communication over HDMI, other the CEC. And I'm not sure if CEC can be used to negotiate the format. (Probably not?)The I2C lines (Vesa DDC / EDID) is only unidirectional as far as I can tell. Signal source reads (read-only) content from the sink and opts to behave accordingly to the list of supported formats, as encoded in the DDC memory.HDMI is unfortunately a lot of mystery, as it is a heavily commercialized pay-walled interface, just like MIPI. You're not simply gonna get any specs for it, sometimes you are not even gonna get full datasheets for ICs that interface either of those two. Doh!

author: soldar
author_rank: Super Contributor
timestamp: November 12, 2019, 07:13:43 pm
content: So a source which can send audio in a dozen different formats would send them all out simultaneously and let the receivers choose? That seems not very efficient to me, but, again, I know close to nothing about this topic and I am just speculating.

author: Yansi
author_rank: Super Contributor
timestamp: November 12, 2019, 07:38:40 pm
content: I do not think there is a dozen formats. Barely half a dozen.From a quick search about HDMI, I found that only 2 main encoding schemes are available, times 3 different sampling/bit-rates:Either it is LPCM (linear non-compressed data) in 48, 192 or 384kHz sampling times two 32bit channels,or it is some kind of Dolby compressed whatever, using the same audio data channel resulting in three different bitrates: either 1.5, 6 or 25mbps. I am no expert on HDMI, just investigated viability of HDMI for one of my projects (concluded it is not), so I have just a bare minimum knowledge of how it works. Inaccessible documentation was a showstopper. (I ended up with a DVI and some obscure encoder chip from Chrontel).https://developer.dolby.com/blog/dolby-audio-over-hdmi-part-2-signaling-and-carriage/

author: soldar
author_rank: Super Contributor
timestamp: November 12, 2019, 07:48:53 pm
content: I cannot imagine sending all possible formats at once. It just makes no sense to me. And Wikipedia says the receiver can communicate "upstream".Quote

author: Yansi
author_rank: Super Contributor
timestamp: November 12, 2019, 07:59:50 pm
content: Hard to argue, hopefully someone with more info (and proper documentation) can enlighten us.

author: soldar
author_rank: Super Contributor
timestamp: November 12, 2019, 08:51:12 pm
content: I guess it could be that the user would select manually from a menu the audio format. That seems pretty easy to do.

author: ve7xen
author_rank: Super Contributor
timestamp: November 12, 2019, 09:47:28 pm
content: I believe it's just re-framed S/PDIF packed into the data islands, so format detection would happen more or less the same as it does with an S/PDIF receiver. Which is to say "not in a very well defined manner".

author: NiHaoMike
author_rank: Super Contributor
timestamp: November 13, 2019, 01:45:27 am
content: Quote from: ve7xen on November 12, 2019, 09:47:28 pmExcept HDMI supports a bunch of audio formats S/PDIF does not.

author: hamster_nz
author_rank: Super Contributor
timestamp: November 13, 2019, 03:33:16 am
content: Looking through the HDMI Standard 1.4 (search for "hdmi 1.4 standard filetype:pdf") it looks like there are two ways to transmit audio.- A packet that contains audio samples, and metadata bits out of the S/PDIF stream.- A one-bit audio packet. That I assume moves raw bits from source to sink.Looking at the S/PDIF info athttp://www.hardwarebook.info/S/PDIF,I would guess that the coding is transmitted in the "Channel status and subcode information".I assume that the source asked over E-DID what formats are supported, then sends a standard S/PDIF stream with the correct metadata for the desired audio format.If the stream is not compatible for with SPDIF framing/packets I assume the raw stream of bits is transmitted over a one-bit audio packet...

author: cvanc
author_rank: Frequent Contributor
timestamp: November 13, 2019, 03:57:37 am
content: Wouldn't the easiest answer be to just use a surround sound receiver and observe what format it detects?Or am I misunderstanding your goal here?

author: teddyng
author_rank: Newbie
timestamp: November 13, 2019, 10:38:10 am
content: Quote from: cvanc on November 13, 2019, 03:57:37 amThat's what I am doing at the moment with a receiver, but I am trying to build a portable one.

author: teddyng
author_rank: Newbie
timestamp: November 13, 2019, 10:55:44 am
content: Quote from: Yansi on November 12, 2019, 04:38:45 pmI will probably do some sink simulation to find out the handshake process if any.Thanks for all the info so far, I will do a bit more research and I also have access to a few quantumdata analysers so I can double check where the audio signal is being send and look at the EDID and infoframes, I will keep you guys updated. The main problem might be building a circuit with their proprietary chipset as Yansi mentioned which the datasheet or where I can get hold of them. I might buy a "HDMI Audio Extractor" from Amazon which might have a "smart" decoder chipset that also process the EDID/infoframes, but it might have a "dumb" chip/chipset that just pull the audio out without the handshake.

author: NiHaoMike
author_rank: Super Contributor
timestamp: November 13, 2019, 01:23:18 pm
content: Quote from: teddyng on November 13, 2019, 10:38:10 amFind a used receiver with a blown PSU or output stage, then scavenge the HDMI board and display?