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
options HDAUDIO_ENABLE_HDMI
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
output.)
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.
kre
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.)