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
next prev parent 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).