[Bug 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=39832


James Cloos <cloos at jhcloos.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cloos at jhcloos.com




--- Comment #17 from James Cloos <cloos at jhcloos.com>  2011-09-03 11:00:01 ---
[I tried to send this via mail; but that pends hera’s return....]

I occasionally have to connect my compute node to the TV in the other
room to fix or diagnose issues, and looked into the hdmi audio the last
time I did so.

While using KMS, the TV constantly complained that the audio packets
were corrupt.

After moving the box back, I extended the EDID reporting tools to handle
the audio bits and found that the TV only advertises support for 16 bit
48 kHz PCM 2-channel stereo audio.  ALSA, OTOH, was trying to send 5.1.

Some time ago I read a thread on some list (lkml? xorg-driver-ati?)
where the decision was made to ignore the EDID advertisements because
some hdmi switches (I presume amplifiers) pass through the TV’s EDID
even though they support more audio options and do not pass the audio
through to the TV.

I suspect, but have not had the opportunity to test, that forcing the
driver to only send 16 bit 48 kHz PCM 2-channel stereo audio would
appease the TV and allow things to Just Work™.

I additionally suspect that were I to place an hdmi-connected amp
between the box and the TV things also would Just Work.

If so, the proper solution is to honour the EDID advert by default
and to provide sysfs configuration to override the EDID limits and
to specify the set of audio options which the driver may output
over the hdmi link.

Some of the legacy ati cards get their hdmi audio support from a
different file in the kernel src; that file limits output to two
audio channels.  Adding one’s card’s pci id to that driver and
recompiling the kernel might be a reasonable way to test my
hypothesis – a method I’ve prepared to do the next time I need
to lug the box out there.  Edit sound/pci/hda/patch_hdmi.c and
add something like:

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index bd0ae69..3870853 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1632,2 +1632,3 @@ static const struct hda_codec_preset
snd_hda_preset_hdmi[] = {
 { .id = 0x1002791a, .name = "RS690/780 HDMI",  .patch = patch_atihdmi },
+{ .id = 0x1002970f, .name = "RS880 HDMI",      .patch = patch_atihdmi },
 { .id = 0x1002aa01, .name = "R6xx HDMI",       .patch = patch_generic_hdmi },
@@ -1679,2 +1680,3 @@ MODULE_ALIAS("snd-hda-codec-id:10027919");
 MODULE_ALIAS("snd-hda-codec-id:1002791a");
+MODULE_ALIAS("snd-hda-codec-id:1002970f");
 MODULE_ALIAS("snd-hda-codec-id:1002aa01");

(where 0x1002970f is the id of the 890GX chipset’s onboard graphics).

I cannot do much testing here (unless someone wants to loan me a 10+
meter hdmi cable and a wireless keyboard ☺); lugging that box around
is a RPITA™.  But I’ll do what I can.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.