[alsa-devel] [PATCH] ALSA: hda - Avoid outputting HDMI audio before prepare() and after close()

[Takashi Iwai]

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 <anssi.hannula at iki.fi>
> > Cc: stable at 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