Bug 39832 - HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
Status: NEW
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel)
All Linux
: P1 normal
Assigned To: drivers_video-dri
:
Depends on:
Blocks: 36912
  Show dependency treegraph
 
Reported: 2011-07-23 01:36 UTC by Andreas Steinmetz
Modified: 2013-12-23 14:13 UTC (History)
14 users (show)

See Also:
Kernel Version: 3.4.4
Tree: Mainline
Regression: Yes


Attachments

Description Andreas Steinmetz 2011-07-23 01:36:12 UTC
There is no sound output via HDMI with kernel 3.0 on a MSI Wind Nettop whereas sound output with kernel 2.6.39.3 works.

PCI device in question:

02:00.0 VGA compatible controller: ATI Technologies Inc M92 LP [Mobility Radeon HD 4300 Series]
02:00.1 Audio device: ATI Technologies Inc RV710/730

Device of "alsamixer":

Card: HDA ATI HDMI
Chip: ATI R6xx HDMI

Boot message for working 2.6.39.3:

HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
HDA Intel 0000:00:1b.0: setting latency timer to 64
hda_codec: ALC888: BIOS auto-probing.
HDA Intel 0000:02:00.1: PCI INT B -> GSI 18 (level, low) -> IRQ 18
HDA Intel 0000:02:00.1: setting latency timer to 64
ALSA device list:
  #0: HDA Intel at 0xfe7fc000 irq 16
  #1: HDA ATI HDMI at 0xfe9ec000 irq 18

Boot message for broken 3.0:

HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
HDA Intel 0000:00:1b.0: setting latency timer to 64
hda_codec: ALC888: BIOS auto-probing.
HDA Intel 0000:02:00.1: PCI INT B -> GSI 18 (level, low) -> IRQ 18
HDA Intel 0000:02:00.1: setting latency timer to 64
HDMI status: Pin=3 Presence_Detect=0 ELD_Valid=0
input: HDA ATI HDMI HDMI/DP as /devices/pci0000:00/0000:00:1c.1/0000:02:00.1/sou
nd/card1/input5

Contents of /proc/asound/cards (2.6.39.3 and 3.0):

 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xfe7fc000 irq 16
 1 [HDMI           ]: HDA-Intel - HDA ATI HDMI
                      HDA ATI HDMI at 0xfe9ec000 irq 18

/etc/asound.conf used for both kernels:

pcm.!default {
        type plug
        slave.pcm "hdmidev"
}

pcm.hdmidev {
        type dmix
        ipc_key 1024
        slave {
                pcm {
                        type hw
                        card 1
                        device 3
                }
        }
}

ctl.hdmidev {
        type hw
        card 1
        device 3
}
Comment 1 Takashi Iwai 2011-07-26 13:18:49 UTC
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).
Comment 2 Takashi Iwai 2011-07-26 13:22:21 UTC
Anyway, try to replace sound/pci/hda/hda_intel.c with the one in 2.6.39.
Does it fix the problem?
Comment 3 Andreas Steinmetz 2011-07-26 23:19:59 UTC
Sorry, that doesn't fix it.
Comment 4 Takashi Iwai 2011-07-27 05:21:40 UTC
OK, it means that it's no bug of the sound driver, but something else.
As mentioned, likely a video driver problem.
Comment 5 Andreas Steinmetz 2011-08-09 18:12:02 UTC
Problem is still there in 3.0.1
Comment 6 Takashi Iwai 2011-08-09 19:18:27 UTC
Could you bisect?
Comment 7 Andreas Steinmetz 2011-08-10 00:16:32 UTC
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
Comment 8 Takashi Iwai 2011-08-10 05:35:08 UTC
Ah, this looks really suspicious.

What happens if you pass radeon.audio=1 option as suggested in the commit log?
Comment 9 Andreas Steinmetz 2011-08-10 10:00:12 UTC
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.
Comment 10 Takashi Iwai 2011-08-10 10:32:56 UTC
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.
Comment 11 Michel Dänzer 2011-08-29 17:46:25 UTC
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?
Comment 12 Andreas Steinmetz 2011-09-02 00:21:00 UTC
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.
Comment 13 Florian Mickler 2011-09-02 09:47:04 UTC
(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.
Comment 14 Alex Deucher 2011-09-02 13:44:29 UTC
(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.
Comment 15 Xavier Bestel 2011-09-02 14:19:17 UTC
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.
Comment 16 Alex Deucher 2011-09-02 14:33:03 UTC
(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.
Comment 17 James Cloos 2011-09-03 11:00:01 UTC
[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.
Comment 18 Florian Mickler 2012-01-24 23:15:56 UTC
Is this still a problem in 3.2 / 3.3-rc1?
Comment 19 Jonathan Nieder 2012-02-17 05:38:13 UTC
(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
Comment 20 Carlos 2012-05-15 20:53:42 UTC
I can confirm that this bug still a problem Kernel Linux 3.2.0. I tried everything I found all forums. Simply doesnt work.
Comment 21 Rafał Miłecki 2012-05-17 07:14:14 UTC
(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
Comment 22 Carlos 2012-05-17 11:14:02 UTC
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.
Comment 23 Santiago Garcia Mantinan 2012-05-25 06:21:20 UTC
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.
Comment 24 Santiago Garcia Mantinan 2012-05-25 07:35:48 UTC
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.
Comment 25 Santiago Garcia Mantinan 2012-07-16 06:54:36 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.