[alsa-devel] HD-Audio/HDMI: avoid missing start of audio stream on audio reconfiguation or after S3

[Lin, Mengdong]

Hi Takashi,

We hope to continue discussing the workaround to avoid HDMI data missing when audio configuration changes (eg. stereo ->5.1 channel) or after S3.

The basic idea is to insert silent audio stream playback on audio configuration changes.
Please see updates below ...

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Thursday, December 19, 2013 9:27 PM
> To: Lin, Mengdong
> Cc: Wu, Fengguang; Li, Jocelyn; Girdwood, Liam R; Chehab, John
> Subject: Re: Could you share some advice to check missing start of audio
> stream in HDMI audio playback?
> 
> At Thu, 19 Dec 2013 12:45:03 +0000,
> Lin, Mengdong wrote:
> >
> > Many thanks, Takashi and Fengguang!
> >
> > Windows team met same issue. They also confirmed the latency for
> monitor/AV receiver to reconfigure audio setup is not avoidable.
> >
> > And their workaround is to send silent audio data after each stream
> reconfiguration, before playing back the valid audio stream.
> >
> > Do you feel this workaround should be implemented in driver or in
> user-space?
> 
> Hard to say.  An easier for us would be user-space, but it can be done in
> the driver (e.g. in the prepare callback), too, although the implementation
> would become tricky.  We'd need a static silence page and play it in
> hda_intel.c as a special requirement in the prepare, then set the BLD back
> to the normal buffer at the end of azx_pcm_prepare().  A bit complex,
> but certainly doable.

For Intel display engine, including Haswell/Ivybridg/Sandibridge, HW can generate silent audio data on driver request during a link underrun.
So for these platforms, we can 
- enable this "HW internal fabrication" feature in i915 driver. HW supported 32kHz, N*44,1kHz, N*48kHz.
- and add specified sleep at the end of azx_pcm_prepare() or generic_hdmi_playback_pcm_prepare()

This can avoid audio driver to prepare silent data and transmit over HD-A link. Is it doable?

> > Doing this in may generate extra latency to open a stream. And the
> length of the steam depends on experience.
> 
> Yes, it's purely depending on the receiver hardware.

Can we add a kernel parameter to specify the length of the silent stream?
It could be 0 by default, meaning no silent stream insertion and thus no extra latency for playback.

> 
> > And silent streams in different formats need to be prepared since there
> can be wrapped compressed stream for playback.
> > So I'd like such a workaround in audio middleware in user-space.
> 
> For the compress audio, it's a bit different problem, indeed.

We need to check whether HW supports compressed data format.
But at least we can apply this feature on PCM format.

Thanks
Mengdong
 
> 
> Takashi
> 
> > Thanks
> > Mengdong
> >
> > > -----Original Message-----
> > > From: Takashi Iwai [mailto:tiwai at suse.de]
> > > Sent: Thursday, December 19, 2013 7:55 PM
> > > To: Wu, Fengguang
> > > Cc: Lin, Mengdong; Li, Jocelyn; Girdwood, Liam R; Chehab, John
> > > Subject: Re: Could you share some advice to check missing start of
> > > audio stream in HDMI audio playback?
> > >
> > > At Thu, 19 Dec 2013 15:38:40 +0800,
> > > Fengguang Wu wrote:
> > > >
> > > > Mengdong,
> > > >
> > > > On Thu, Dec 19, 2013 at 02:30:33PM +0800, Lin, Mengdong wrote:
> > > > > Hi Takashi/Fengguang
> > > > >
> > > > >
> > > > >
> > > > > Sorry to interrupt. Would you please share some advice to check
> > > > > a HDMI audio issue below?
> > > > >
> > > > >
> > > > >
> > > > > For HDMI audio playback under Linux on Haswell/Valleyview, start
> > > > > of an audio stream (2~4 seconds) may be missing before we can
> > > > > hear the
> > > sound, in two cases:
> > > > >
> > > > > -          1^st playback after S3. First several seconds of audio
> > > stream can be
> > > > > missing for some monitor, while other monitor does not have this
> > > issue.
> > > > >
> > > > > -          Switching from playing stereo PCM to 5.1 channel
> PCM.
> > > About first 2
> > > > > seconds of the 5.1 channel PCM cannot be heard from the AV
> receiver.
> > > > >
> > > > >
> > > > >
> > > > > It seems some monitor/AV receiver can drop audio data before
> > > > > playing sound. We wonder if we could improve in audio/gfx driver.
> > > > >
> > > > > Have you ever met similar issue on previous platforms?
> > > > >
> > > > >
> > > > >
> > > > > We’ll be appreciated if you could share us some tips to check
> > > > > this
> > > issue.
> > > > >
> > > >
> > > > I once fixed a similar issue, hope it's useful information for you.
> > > >
> > > > commit 5779191e0efd851fb0d54698c13cb4f5325caca6
> > > > Author:     Wu Fengguang <fengguang.wu at intel.com>
> > > > AuthorDate: Wed Nov 18 12:38:06 2009 +0800
> > > > Commit:     Takashi Iwai <tiwai at suse.de>
> > > > CommitDate: Wed Nov 18 07:46:19 2009 +0100
> > > >
> > > >     ALSA: intelhdmi - sticky stream id and format
> > > >
> > > >     We tracked down the first-0.5s-hdmi-audio-samples-lost
> problem
> > > to the
> > > >     AC_VERB_SET_CHANNEL_STREAMID command. It is suspected
> that
> > > many HDMI
> > > >     sinks need some time to adapt to the new state.
> > > >
> > > >     The workaround is to avoid changing stream id/format
> whenever
> > > possible.
> > > >     Proposed by David.
> > > >
> > > >     Signed-off-by: David Härdeman <david at hardeman.nu>
> > > >     Signed-off-by: Wu Fengguang <fengguang.wu at intel.com>
> > > >     Signed-off-by: Takashi Iwai <tiwai at suse.de>
> > >
> > > Yeah, sounds like a similar problem.
> > >
> > > In general, such a kind of drop is due to the receiver trying to
> > > synchronize the stream at the beginning of the playback.  So, the
> > > patch above essentially keeps the audio widget untouched as long as
> > > it's left unchanged.  But, after S3, this can't be avoided.  Ditto
> > > for changing from stereo to 5.1.  It's reconfiguring the audio setup
> > > bits, thus it has to be reset.  That said, the problem is likely
> unavoidable in both situations.
> > >
> > > Of course, my wile guess might be wrong.  I'd apply happily any fix
> > > patches :)
> > >
> > >
> > > Takashi