Bug 51421 - Enabling HDMI sound makes HDMI video flicker (and no sound is heard)
Enabling HDMI sound makes HDMI video flicker (and no sound is heard)
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA)
All Linux
: P1 normal
Assigned To: Jaroslav Kysela
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-08 02:46 UTC by Rogério Brito
Modified: 2013-01-07 17:24 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.6
Tree: Mainline
Regression: No


Attachments
Output of lspci (2.19 KB, text/plain)
2012-12-08 02:46 UTC, Rogério Brito
Details
Output of lspci -n (756 bytes, text/plain)
2012-12-08 02:46 UTC, Rogério Brito
Details
Output of alsa-info.sh (33.00 KB, text/x-log)
2012-12-10 15:57 UTC, Rogério Brito
Details
Output of alsa-info.sh after applying the patch suggested by Takashi (96.82 KB, text/x-log)
2012-12-14 06:12 UTC, Rogério Brito
Details
Patch to set pins ON constantly (1.61 KB, patch)
2012-12-14 09:00 UTC, Takashi Iwai
Details | Diff
Fix patch (3.00 KB, patch)
2012-12-14 09:31 UTC, Takashi Iwai
Details | Diff

Description Rogério Brito 2012-12-08 02:46:17 UTC
Created attachment 88631 [details]
Output of lspci

Hi.

First of all, I don't quite know where I should send this bug report and I would appreciate it to be directed to a proper place where this should be discussed.

OK, so I have an Itautec Note N8320 notebook (which is actually a rebranded MSI PR200). According to lspci, the notebook has a GM965/GL960 video controller and an Intel Corporation 82801H (ICH8 Family) HD audio controller.

I tried to use its HDMI port to connect it to my TV and things went fine when I used "gnome-control-center display" to send the desktop to the TV only (it actually worked fine when both the internal LCD and the TV were enabled).

At this point, I could play a video with, say, mplayer and have it output its image to the TV and sound via the notebook's internal speaker.

Unfortunately, when I chose to output audio via the HDMI cable (with gnome-control-center sound and pulseaudio installed), I got a strange behavior as soon as I started mplayer (which meant starting sending sound via the HDMI cable): the screen of the TV started to flicker periodically (at about 2 to 3 seconds) as if I had been disconnecting and connecting the HDMI cable and the TV tried to "sync" the image to be displayed.

Also, no sound is played by the TV (only video, when it is not "flickering") if tell that the sound should be sent by the HDMI cable.

To rule out problems on the kernel side, I tried both Debian's precompiled 3.6 kernel and 3.2, with the same result in both cases.

As I said before, I don't know exactly where this problem could lie, but I can provide as many details as wanted about this system.

I will attach to this bugzilla entry the output of lspci for starters, but feel free to let me know if any other information is needed to fix this odd behavior.

Thanks in advance for any help,

Rogério Brito.


P.S.: With another notebook (same userland, but Sandy Bridge-based), I followed the exact same steps and everything was flawless (i.e., both audio and video sent via HDMI to the TV).
Comment 1 Rogério Brito 2012-12-08 02:46:57 UTC
Created attachment 88641 [details]
Output of lspci -n
Comment 2 Takashi Iwai 2012-12-08 08:12:36 UTC
Could you give alsa-info.sh output?  First of all, we need to check in which route the HDMI audio is sent.  On old hardware, it might be sent over the codec's digital output pin while the recent Intel graphics provide the own HDMI audio controller.
Comment 3 Rogério Brito 2012-12-08 20:47:15 UTC
(In reply to comment #2)
> Could you give alsa-info.sh output?
> First of all, we need to check in which route the HDMI audio is sent.
> On old hardware, it might be sent over the codec's digital output pin
> while the recent Intel graphics provide the own HDMI audio controller.

Dear Takashi, first of all, thanks for replying.

The output of alsa-info.sh is at:

    http://www.alsa-project.org/db/?f=4e32e3a5f8a345d26512b9dd2002d398b68cfe66

I know that you can make sense of all that, but I don't even know where to start. :)

Anyway, if you need more information, please let me know and I will do my best to collect it.


Thanks again,

Rogério Brito.
Comment 4 Rogério Brito 2012-12-10 15:57:14 UTC
Just to prevent the information output by alsa-info.sh from getting lost, I am attaching it to this bug report.

Just to reiterate, if any further information is needed, please let me know and I will do my best to collect it.


Thanks,

Rogério Brito.
Comment 5 Rogério Brito 2012-12-10 15:57:45 UTC
Created attachment 88851 [details]
Output of alsa-info.sh
Comment 6 Takashi Iwai 2012-12-10 16:18:05 UTC
Thanks.  So this is an old SiI 1392 HDMI codec.  This codec is supposed to work as a generic codec, but I don't think this has been tested well.

What happens if you change the code like below?

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2280,7 +2280,7 @@ static const struct hda_codec_preset snd_hda_preset_hdmi[] = {
 { .id = 0x1002791a, .name = "RS690/780 HDMI",	.patch = patch_atihdmi },
 { .id = 0x1002aa01, .name = "R6xx HDMI",	.patch = patch_generic_hdmi },
 { .id = 0x10951390, .name = "SiI1390 HDMI",	.patch = patch_generic_hdmi },
-{ .id = 0x10951392, .name = "SiI1392 HDMI",	.patch = patch_generic_hdmi },
+{ .id = 0x10951392, .name = "SiI1392 HDMI",	.patch = patch_atihdmi },
 { .id = 0x17e80047, .name = "Chrontel HDMI",	.patch = patch_generic_hdmi },
 { .id = 0x10de0002, .name = "MCP77/78 HDMI",	.patch = patch_nvhdmi_8ch_7x },
 { .id = 0x10de0003, .name = "MCP77/78 HDMI",	.patch = patch_nvhdmi_8ch_7x },
Comment 7 Rogério Brito 2012-12-14 06:12:17 UTC
Created attachment 89161 [details]
Output of alsa-info.sh after applying the patch suggested by Takashi

Hi, Takashi and others.

Sorry for the delay in the response, but I didn't see the message until now. As soon as I saw it, I started compiling the kernel.

OK, so bugzilla doesn't preserves patches and I manually changed the line with "SiI1392 HDMI" to just have patch_atihdm instead of patch_generic_hdmi.

The result is that I now don't get the screen flickering, but, OTOH, I don't get any sound if I change from the internal speakers to the HDMI output.

Should I try other combinations of patch_* for that field (if that is productive at all)? Or should we go in another direction?


Thank you very much for the help so far,

Rogério Brito.
Comment 8 Rogério Brito 2012-12-14 06:14:31 UTC
Oh, just for completeness, the new output of alsa-info is also at:

http://www.alsa-project.org/db/?f=86f4c21710fb5017ef73bd372f91ff6d709585d6

Thanks,
Rogério.
Comment 9 Takashi Iwai 2012-12-14 07:20:12 UTC
(In reply to comment #7)
> Created an attachment (id=89161) [details]
> Output of alsa-info.sh after applying the patch suggested by Takashi
> 
> Hi, Takashi and others.
> 
> Sorry for the delay in the response, but I didn't see the message until now. As
> soon as I saw it, I started compiling the kernel.
> 
> OK, so bugzilla doesn't preserves patches and I manually changed the line with
> "SiI1392 HDMI" to just have patch_atihdm instead of patch_generic_hdmi.
> 
> The result is that I now don't get the screen flickering, but, OTOH, I don't
> get any sound if I change from the internal speakers to the HDMI output.

I thought the sound didn't come out of TV even without patching, right?
If so, "no sound from TV" itself is no regression.

> Should I try other combinations of patch_* for that field (if that is
> productive at all)?

Unlikely helpful.

Since patch_atihdmi() didn't give flickering, the HDMI audio infoframe setup might be the culprit.

Could you try to comment out the call of hdmi_setup_audio_infoframe() in patch_hdmi.c generic_hdmi_playback_pcm_prepare()?  (Revert back your previous modification before that.)
If my guess is correct, this should stop flickering.  But the sound won't come out (unless matching casually).
Comment 10 Rogério Brito 2012-12-14 08:24:30 UTC
Hi, Takashi.

On Fri, Dec 14, 2012 at 5:20 AM,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=51421
>
> I thought the sound didn't come out of TV even without patching, right?
> If so, "no sound from TV" itself is no regression.

Yes, indeed. :)

> Since patch_atihdmi() didn't give flickering, the HDMI audio infoframe setup
> might be the culprit.
>
> Could you try to comment out the call of hdmi_setup_audio_infoframe() in
> patch_hdmi.c generic_hdmi_playback_pcm_prepare()?  (Revert back your previous
> modification before that.)

OK, just did that.

> If my guess is correct, this should stop flickering.  But the sound won't come
> out (unless matching casually).

I'm compiling the kernel and will post the result that I get.


Thanks once again,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Comment 11 Rogério Brito 2012-12-14 08:49:05 UTC
Hi.

Unfortunately, after booting with the kernel with generic_hdmi_playback_pcm_prepare commented out, I get the same flickering behavior than before.

The output from alsa-info is at:

    http://www.alsa-project.org/db/?f=ea7c74bef7eb6647ac8b74ac1045c0a412c639b9

Let me be a bit more precise here, since I observed with more attention when the flickering occurs:

* When testing with mplayer playing a video, it only "flickers" about 1 second after the playback begins. Then, there's no flickering anymore. Then, when I stop the video, about 1 second after that I get another flicker and that's it.

* The constant flickering that I was seeing was when I was running xbmc here. As its interface is full of sounds for feedback purposes, I was seeing the screen flickering all the time.

The layman in me would think, given the above, that the flickers only happen when the audio channel is being opened/closed. Is that a sensible guess?


Thanks for all the support,

Rogério Brito.
Comment 12 Rogério Brito 2012-12-14 08:52:05 UTC
(In reply to comment #11)
> Unfortunately, after booting with the kernel with
> generic_hdmi_playback_pcm_prepare commented out, I get the same flickering
> behavior than before.

Correction: I commented out hdmi_setup_audio_infoframe from generic_hdmi_playback_pcm_prepare, *NOT* what I miswrote above.

Thanks again,

Rogério Brito.
Comment 13 Takashi Iwai 2012-12-14 09:00:26 UTC
OK, then this is not about the audio infoframe, but maybe the part setting the pin-control on/off on demand.

How about the patch below?  You can discard the previous changes.
Comment 14 Takashi Iwai 2012-12-14 09:00:58 UTC
Created attachment 89181 [details]
Patch to set pins ON constantly
Comment 15 Rogério Brito 2012-12-14 09:13:55 UTC
(In reply to comment #13)
> OK, then this is not about the audio infoframe, but maybe the part setting the
> pin-control on/off on demand.
> 
> How about the patch below?  You can discard the previous changes.

OK, just tried it. I get no flicker (but no sound, not sure if this was still expected to be so).


Thanks,

Rogério.
Comment 16 Rogério Brito 2012-12-14 09:23:58 UTC
I've gotta go right now, but tonight (I'm here in Brazil) I will test anything else that you want me to and report what I see.
Comment 17 Takashi Iwai 2012-12-14 09:31:00 UTC
Good to hear that it stops flickering.

"no sound" is more or less expected because it didn't work with the original version.  I guess it's rather a problem in the video driver side.
Please open another bug for tracking it, assign the component DRI Intel.

Meanwhile I'm going to queue the fix for setting the pin constantly.
Comment 18 Takashi Iwai 2012-12-14 09:31:23 UTC
Created attachment 89211 [details]
Fix patch
Comment 19 Florian Mickler 2012-12-22 09:30:54 UTC
A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit 6169b673618bf0b2518ce413b54925782a603f06
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Dec 14 10:22:35 2012 +0100

    ALSA: hda - Always turn on pins for HDMI/DP

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