Bug 51421

Created attachment 88641 [details]
Output of lspci -n

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.

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

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.

Created attachment 88851 [details]
Output of alsa-info.sh

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 },

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.

Oh, just for completeness, the new output of alsa-info is also at:

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

Thanks,
Rogério.

(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).

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

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.

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

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.

Created attachment 89181 [details]
Patch to set pins ON constantly

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

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.

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.

Created attachment 89211 [details]
Fix patch

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