Bug 39832

The "HDMI status:..." message is new and it doesn't mean any new bug.  And there aren't so many difference that can affect to ATI HDMI code.

The problem is that the HDMI controller doesn't give the proper ELD bits.  This is usually a bug in the video-driver side (remember that HDMI-audio is always coupled with video).

Anyway, try to replace sound/pci/hda/hda_intel.c with the one in 2.6.39.
Does it fix the problem?

Sorry, that doesn't fix it.

OK, it means that it's no bug of the sound driver, but something else.
As mentioned, likely a video driver problem.

Problem is still there in 3.0.1

Could you bisect?

Bisect between 2.6.39 and 3.0 gives:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
18367c0ec73671fbfea35f13ae52d39437c53eb5
d364ee4fdb33a329b16cdf9342e9770b4d4ddc83
76df01eacd5fa41b607426a8cb091fb21ae35554
805c22168da76a65c978017d0fe0d59cd048e995
81de916f19cf5f1437c0b9ed817364f0f7c81961
46671b035504eb345124b4b275b37726a48bdbaa
We cannot bisect more!

Now this sounds suspiciously like the following commit:

[805c22168da76a65c978017d0fe0d59cd048e995] drm/radeon/kms: disable hdmi audio by default

Ah, this looks really suspicious.

What happens if you pass radeon.audio=1 option as suggested in the commit log?

Now that works. But:

1. Why is a sane and working default all of sudden broken? As the default was working audio a "noaudio" kernel parameter to radeon whould have been the sane way of handling this. Politically linux was always "do not break user space" and the radeon change simply violates this. And even though it is technically sensible an audio device option for a video card is at least, ahem, unexpected.

2. Why alsa shows the HDMI audio device in /proc/asound/cards when the device is actually disabled and thus not available? I would have looked for kernel changes in this case (alsa HDMI audio device gone). The current behaviour (disabled device displayed, "usable" without sound) for sure will bite others. If the HDMI audio device can be switched on and off it should be treated by alsa like a usb or firewire audio device.

I don't know of detail about 1, but the git changelog says 
  "The current RE'd code causes blank screens and display problems on a lot of systems.  So disable t by default for now."
I find it's also bad to change in that way, though.

About 2: you can't see the changes in the video driver from the sound codec side.  Note that HDMI provides separate components for video and audio, and they are treated completely individually.

Anyway, please check the bugzilla component to the appropriate one.  It's no ALSA problem after all.  Thanks.

If you want to consider this a regression, it was caused by the currently best known fix for another regression: enabling HDMI audio by default caused blank screens and display problems. Are you seriously suggesting going back to that would be the better?

I am suggesting that if audio is disabled by default the HDMI output must not be advertised as an alsa device. If the device is not there users will look for
what switch to use to enable the device if the device works for them with no side effects. The way it is now is a cable that is plugged in on both sides but after a long search is apparently broken somewhere in between. You know, probably from experience, that this state of affairs is no fun. That's what I'm seriously suggesting.

(I don't know the details of this bug, but am just responding to comment #11)
@Michel: Fixing regressions without introducing other regressions is a prerequisite for being sure of forward progress. Else it's possible we are going in circles. The policy on the linux kernel is: no regressions. So, we revert even fixes if they cause _new_ regressions.

(In reply to comment #13)
> (I don't know the details of this bug, but am just responding to comment #11)
> @Michel: Fixing regressions without introducing other regressions is a
> prerequisite for being sure of forward progress. Else it's possible we are
> going in circles. The policy on the linux kernel is: no regressions. So, we
> revert even fixes if they cause _new_ regressions.

Not being able to see your screen(s) seems like a bigger issue than having to set an option to enable audio.  Although, audio support itself regressed working video for the bad cases originally, so audio support was a regression as well for some people.

I think the problem is that the audio device is *advertised* as working, although it doesn't.
radeon should just stop advertising audio if radeon.audio isn't set.

(In reply to comment #15)
> I think the problem is that the audio device is *advertised* as working,
> although it doesn't.
> radeon should just stop advertising audio if radeon.audio isn't set.

The GPU driver doesn't advertise/handle the audio device.  The alsa driver does.  All the GPU driver does is enable the audio packets in the HDMI stream.  I don't think there's a way for the gpu driver to tell the alsa driver not to load.  Moreover, there are audio devices on certain boards with where the audio can be sent to either hdmi or regular audio ports so you would still want it that case.

[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.

Is this still a problem in 3.2 / 3.3-rc1?

(In reply to comment #18)
> Is this still a problem in 3.2 / 3.3-rc1?

Here's a report using 3.0 and 3.2.4:
http://bugs.debian.org/659673

I can confirm that this bug still a problem Kernel Linux 3.2.0. I tried everything I found all forums. Simply doesnt work.

(In reply to comment #20)
> I can confirm that this bug still a problem Kernel Linux 3.2.0. I tried
> everything I found all forums. Simply doesnt work.

This bug(report) is only about disabling audio by default. By setting radeon.audio=1 you go back to the earlier behavior.

So I guess you must be seeing another issue, please create another bug report or ask for help for ex. at: dri-devel@lists.freedesktop

Thanks for the reply. In fact, I already try the radeon.audio=1 settings, as well to play sound with command  sudo aplay -D plughw:1,3 (music).mp3 and nothing. I tried as well kernel 3.3 no luck. I will create another bug.

Hi, I'm the one that submitted the problem in Comment #19 From Jonathan Nieder, I have now uploaded to alsa the alsa-info.sh collected data and tests include 3.3.6.

Here are the kernels for which I submitted the info and the link to the info submitted.

ii  linux-image-2.6.39-2-686-pae         2.6.39-3
ii  linux-image-3.2.0-2-686-pae          3.2.17-1
ii  linux-image-3.3.0-trunk-686-pae      3.3.6-1~experimental.1
3.2.17
http://www.alsa-project.org/db/?f=1065dc2b77cb999525747f08238309c2de1013c9
3.3.6
http://www.alsa-project.org/db/?f=499ea9e973c6119416e9356e23451250893048d5
2.6.39
http://www.alsa-project.org/db/?f=9c9b0c9e26c1bc570e15ed12b23d8b6ff1386ae5

I have previously tested 3.0 and 3.1 kernels and were also working, in I had to go to 2.6.39 to find a working kernel.

I don't have access to the machine at anytime that is why it took so long to report back, I hope I can test 3.4 soon but I don't think that will make any change.

Hope this helps identify the bug, regards.

About my previous message... when I talk about 3.0 and 3.1 I meant that they were also failing, not working, 2.6.39 was the last working one for me, I tested all the series since that one and they were all broken.

Hope this clarifies a bit and sorry for the confusion.

I have just tested 3.4.4 and I got no sound again, however this time the kernel said this:

[   81.186129] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

I hope this helps!

Please try this bug with latest kernel image.