Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: HDMI audio attach help wanted

Hi Robert --

The ELD parsing code is incomplete and not really used in the driver for anything other than (apparently doing a poor job) at printing information about the connected display.

It has been a while since I last looked at this, but if I remember correctly, ELD stands for "EDID-like data" and is a block of data shared between the HDMI transmitter and the HD audio device that can be used to help negotiate audio parameters.

For HDMI audio to work correctly, you need to use a drm display driver, and that driver needs to ensure that (1) the HDMI TX is setup in "HDMI" mode (as opposed to "DVI" mode which works fine for video but not much else), and (2) the HDMI TX is setup for audio and is transmitting HDMI audio infoframes to the display.

See if you can get any debug info out of inteldrm, and/or if the version of inteldrm in tree supports audio on your embedded intel graphics chipset.


On Fri, 28 Apr 2017, Robert Elz wrote:

Hi all,

I have a system (core i3 processor, embedded intel graphics, old asus
motherboard) which I mostly use to run my living room clock (display a
large dclock on a smallish display...)  (it also serves over the network
for some development work, but that's irrelevant.)

That stuff all works fine ... but then I thought I could multi-task a
little, and connected its HDMI output to the TV set that is just nearby.

The graphics output from that is fine, but audio does not work.

I have configured a kernel with
in it, but that just results in

hdafg1 at hdaudio0: vendor 8086 product 2805
hdafg1: DP00 8ch: Digital Out [Jack]
hdafg_dd_parse_info: datalen=83
datalen 13 sadcount 2 sizeof sad 3
hdafg1: failed to parse ELD data
hdafg1: 8ch/0ch 48000Hz PCM16*

I also noticed a very similar config output in the dmesg posted by another
user (who was actually seeking help with a quite different problem I
believe - output similar to this, but with different values - it just
happened to be there and I saw it...)

I added some extra debug in src/sys/dev/hdaudio/hdafg_dd.c and it now says...

hdafg1 at hdaudio0: vendor 8086 product 2805
hdafg1: DP00 8ch: Digital Out [Jack]
hdafg_dd_parse_info: datalen=83
ELD header block: flags=10 r1=0 eld_len=9 r2=0
baseline_eld_len=9 (*4 = 36 -> datalen)
ELD Baseline Block: flags: 67 22  0  1 port_id 0 (0) vendor d94d product 3002
hdafg monitor="SONY TV"
Bad lengths: datalen 13 sadcount 2 sizeof sad 3
0:  9  7  7 15  7 50  0  0  0  0  0  0  0
hdafg1: failed to parse ELD data
hdafg1: 8ch/0ch 48000Hz PCM16*

The "9  7  7 15  7 50  0  0  0  0  0  0  0" are the (hex) data in the 13
bytes where only 6 were actually wanted.   (the extra 7 are the 0's on the
end I presume).   (The "0:" is just the offset into that data, for use in
case there happen to be more than 16 bytes of it .. kind of like hexdump

Does anyone have any idea what might be happening there?  Or what any of
that data (aside from the monitor name .. which is kind of obvious, and
correct...) really means?   (Note that for the monitor name, the output
shown is the complete data block - any non ascii chars would have been
printed as \xXX if any had existed, so ELD_MNL(block) for that data must
have been 7 (strlen("SONY TV")) even though the debug did not print that.
Is it possible that 7 is related to the extraneous 7 bytes ?

I can supply the code that produced that debug output if it is needed
but I hope most of it is obvious - values are decimal (%d) where that
makes sense, or hex (%x) for flags, and random stray values - the port_id
is in both hex & decimal (I had no idea which would be best) which is why
the two 0's after it...

Oh, I assume it is obvious, but when this happens, no audio device attaches.


ps: I note that the stray printf's (no ifdef's or anything) left in this
routine (hdafg_dd_parse_info() in hdafg_dd.c) tend to suggest that this
might all be just work in progress...  Provided it is understood that I know
nothing at all about anything related, I'm willing to perform whatever tests
would be useful to assist with debugging this.  Note that "nothing at all"
means I doubt I can work out know how to persuade apps to use this audio if
it does configure correctly, rather than the normal hdafg0 (audio0) on the
sound card (or however modern PCs implement this) which has nothing at all
connected to it (no speakers, headphones, or anything like that.)

Home | Main Index | Thread Index | Old Index