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