From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] ALSA: hda - Avoid outputting HDMI audio before prepare() and after close() Date: Sun, 17 Feb 2013 09:24:53 +0100 Message-ID: References: <511EEDB0.6010603@iki.fi> <1361032822-4041-1-git-send-email-anssi.hannula@iki.fi> <511FF33C.6050709@iki.fi> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id EAB2A261698 for ; Sun, 17 Feb 2013 09:24:53 +0100 (CET) In-Reply-To: <511FF33C.6050709@iki.fi> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Anssi Hannula Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org At Sat, 16 Feb 2013 22:59:40 +0200, Anssi Hannula wrote: > > 16.02.2013 18:40, Anssi Hannula kirjoitti: > > Some HDMI codecs (at least NVIDIA 0x10de000b:0x10de0101:0x100100) start > > transmitting an empty audio stream as soon as PIN_OUT and AC_DIG1_ENABLE > > are enabled. > > > > Since commit 6169b673618bf0b2518ce413b54925782a603f06 ("ALSA: hda - > > Always turn on pins for HDMI/DP") this happens at first open() time, and > > will continue even after close(). > > > > Additionally, some codecs (at least Intel PantherPoint HDMI) currently > > continue transmitting HDMI audio even after close() in case some actual > > audio was output after open() (this happens regardless of PIN_OUT). > > > > Empty HDMI audio transmission when not intended has the effect that a > > possible HDMI audio sink/receiver may prefer the empty HDMI audio stream > > over an actual audio stream on its S/PDIF inputs. > > > > To avoid the issue before first prepare(), set stream format to 0 on > > codec initialization. 0 is not a valid format value for HDMI and will > > prevent the audio stream from being output. > > > > Additionally, at close() time, make sure that the stream is cleaned up. > > This will ensure that the format is reset to 0 at that time, preventing > > audio from being output in that case. > > > > Thanks to OpenELEC developers and users for their help in investigating > > this issue on the affected NVIDIA "ION2" hardware, and for the initial > > bug report of the issue. Testing of the final version on NVIDIA ION2 was > > done by OpenELEC user "MrXIII". Testing on Intel PantherPoint was done > > by myself. > > > > Signed-off-by: Anssi Hannula > > Cc: stable@vger.kernel.org > > --- > > > > This also supersedes the patch I attached yesterday as it fixes both > > cases. > > > > I guess the alternative to this approach would be to fiddle with > > AC_DIG1_ENABLE when preparing and closing the device, but with a quick > > look that seemed to be possibly more complex since AC_DIG1_ENABLE is > > already meddled with at quite a few places in hda_codec.c. > > Hmm... actually, that would not be so much more complex, just making > sure AC_DIG1_ENABLE is off in hdmi_add_cvt() (by e.g. zeroing > AC_VERB_SET_DIGI_CONVERT_1) and making snd_hda_spdif_ctls_unassign() > call "set_spdif_ctls(codec, spdif->nid, 0, -1);". > > However, it would still mean that just a simple snd_pcm_open() could > cause an empty stream to be output (if format is valid), since iec958 > controls are assigned at open() time, and iec958 mute controls > AC_DIG1_ENABLE. Or we could add additional code in hda_codec.c to > prevent AC_DIG1_ENABLE being set if prepare() has not been called. Is the problem fixed if you set codec->no_sticky_stream = 1? Actually, the current behavior is intentional. There have been bug reports that just reopening a device causes the receiver not reacting immediately. In the worst case, it takes a few seconds to sync. So we introduced a mechanism to keep the PCM stream assignment. If your problem is solved by clearing codec->no_stick_stream, we may provide an additional mixer control to turn it on/off, for example, because we can't blindly disable/enable it globally if user's receiver has a problem with the stream sync. thanks, Takashi