alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Anssi Hannula <anssi.hannula@iki.fi>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] ALSA: hda - Avoid outputting HDMI audio before prepare() and after close()
Date: Sat, 16 Feb 2013 22:59:40 +0200	[thread overview]
Message-ID: <511FF33C.6050709@iki.fi> (raw)
In-Reply-To: <1361032822-4041-1-git-send-email-anssi.hannula@iki.fi>

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 <anssi.hannula@iki.fi>
> 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.


> WDYT, is this OK or should we try a AC_DIG1_ENABLE based approach or
> something else?
> 
> 
>  sound/pci/hda/patch_hdmi.c |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index 807a2aa..bcb83c7 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -1253,6 +1253,14 @@ static int hdmi_add_cvt(struct hda_codec *codec, hda_nid_t cvt_nid)
>  	if (err < 0)
>  		return err;
>  
> +	/*
> +	 * 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, which happens at open() time.
> +	 * To avoid that, set format to 0, which is not valid for HDMI.
> +	 */
> +	snd_hda_codec_write(codec, cvt_nid, 0, AC_VERB_SET_STREAM_FORMAT, 0);
> +
>  	spec->num_cvts++;
>  
>  	return 0;
> @@ -1372,6 +1380,12 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo,
>  	struct hdmi_spec_per_pin *per_pin;
>  
>  	if (hinfo->nid) {
> +		/*
> +		 * Make sure no empty audio is output after this point by
> +		 * setting stream format to 0, which is not valid for HDMI.
> +		 */
> +		__snd_hda_codec_cleanup_stream(codec, hinfo->nid, 1);
> +
>  		cvt_idx = cvt_nid_to_cvt_index(spec, hinfo->nid);
>  		if (snd_BUG_ON(cvt_idx < 0))
>  			return -EINVAL;
> 


-- 
Anssi Hannula

  reply	other threads:[~2013-02-16 20:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-16  2:23 HDMI regression on close (was: ALSA: hda - Always turn on pins for HDMI/DP) Anssi Hannula
2013-02-16 16:40 ` [PATCH] ALSA: hda - Avoid outputting HDMI audio before prepare() and after close() Anssi Hannula
2013-02-16 20:59   ` Anssi Hannula [this message]
2013-02-17  8:24     ` Takashi Iwai
2013-02-17 12:23       ` Anssi Hannula
2013-02-17 17:17         ` Takashi Iwai
2013-02-17 17:57           ` Anssi Hannula
2013-02-18 11:03             ` Takashi Iwai
2013-02-18 11:26               ` Anssi Hannula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=511FF33C.6050709@iki.fi \
    --to=anssi.hannula@iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).