[Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard

[Wu Fengguang]

On Wed, Nov 04, 2009 at 06:54:36PM +0800, David Härdeman wrote:
> On Tue, November 3, 2009 15:09, Wu Fengguang wrote:
> > This is interesting. In my ALSA tests on YAMAHA RX1800:
> > (1) 6 channels light up on "speaker-test -c6"
> > (2) 2 channels light up on playing normal music
> > (3) when not playing anything, 2 channels remain light up
> > (4) need to double check the "pause" case
> >
> > So you mean Windows 7 always light up 6 channels for cases (2) and (3),
> > besides case (1)?  (under your 5.1 speaker config)
> 
> Yes, once I've configured a 5.1 speaker setup (using the control panel in
> Windows 7), 6 channels are indicated on the receiver and it stays that way
> for all cases (1) - (4) you mentioned.

OK, thanks.

> >> The windows driver also has some interesting registry entries referring
> >> to
> >> "SilentStream" and "VCFG", the latter probably referring to the VCFG bit
> >> in the digital converter control reg in section 7.3.3.9 of the HDA
> >> spec).
> >
> > Yeah, it's interesting to have some "SilentStream":
> >
> >         V (Validity): This bit affects the "Validity flag," bit[28]
> >         transmitted in each subframe, and enables the S/PDIF
> >         transmitter to maintain connection during error or mute
> >         conditions.
> 
> Is that flag transmitted over HDMI as well? Might need to check more docs
> but perhaps you already know the answer?

Yes, an uncompressed HDMI is send in an IEC 60958-3 compliant stream,
which is defined in "IEC 60958-3 Digital Audio Interface - Part 3:
Consumer Applications, First Edition, 1999".

Obviously the windows Intel HDMI driver can reuse this SPDIF feature :)

> >> Also, it's interesting to note that when I am playing a working audio
> >> sample under Linux, then pause and resume playing (using the UI
> >> controls),
> >> there are no hiccups and no initial silence when the player resumes
> >> (from
> >> a quick reading of the code, the audio infoframe should still be
> >> transmitted, only DMA of audio data is stopped when pcm is paused).
> >
> > Good catch!
> >
> > The stop/start of a playback involves many operations - including the
> > AC_VERB_SET_CHANNEL_STREAMID which seem to directly related to the 0.5s
> > lost samples problem.
> 
> I agree that changing the STREAMID (and perhaps STREAM_FORMAT) seems to
> cause the lost samples.
> 
> I haven't tried your latest patchset yet, I've been busy testing some
> other approaches and reading Intel docs (the HDA spec is spread over quite
> a lot of docs by now).
> 
> In particular I found this document interesting:
> http://download.intel.com/design/chipsets/hdaudio/HDA015-B.pdf
> 
> >From page 11, first paragraph:
> 
>   KeepAlive (Keep Alive Enable): this bit is applicable only to
>   digital converter widget that is associated (selected by) an
>   Output Digital Pin Widget. This bit allows for software
>   programmed control of S/P-DIF, HDMI and Display Port interfaces
>   to continue to provide clocking information to an attached device.
>   Many such digitally connected audio devices can take more than one
>   second to start playing audio after the clock has stopped, which
>   occurs for example when the Converter and/or Digital Pin Widget
>   is placed into a low power state or even just when a stream is
>   stopped for S/P-DIF.
> 
> Which describes the problems we're seeing pretty accurately.
> 
> Unfortunately, the DG45FC HDMI codec doesn't support KeepAlive (I just
> tested by hacking the driver to set that bit and also checked that EPSS is
> reported as zero), but it's still an indication of what needs to be done
> (keep the codec alive basically).

Yes, I confirmed that EPSS=0 on my G45.

> I'm still investigating if it would be possible to create something
> similar to the sticky-infoframe patch but for stream id and stream format
> as well (meaning that they'll stay valid after device close).
> 
> azx_init_stream() from sound/pci/hda/hda_intel.c seems to indicate that
> the stream_id chosen for the HDMI codec will remain static for as long as
> the module is loaded, so I think it should be possible in theory.

Right.

> As a test I've commented out all the code in
> snd_hda_codec_cleanup_stream() from sound/pci/hda/hda_codec.c (meaning
> that the STREAMID will not be set to zero when the audio application
> closes the device, which should still be ok as the stream id is not reused
> and the DMA for that stream is still stopped).
> 
> It actually fixed my silence for the duration of a track problem but there
> is still silence in the beginning of new tracks.
>
> That's not that surprising though, there is still a new STREAMID and
> STREAM_FORMAT being written when the device is reopened and that seems to
> be enough to upset the HDMI codec for half a second, but it looks
> promising.
 
Good to know that :)

> Next up I'll see if I can get the driver to cache the values of STREAMID
> and STREAM_FORMAT and only change them when they actually change without
> having to make extensive changes outside of patch_intelhdmi.
> 
> Anyways, I wouldn't push the fake-audio-infoframe (refer-to-stream-header
> during device close) patches upstream yet, they might just paper over the
> real problem by forcing the receiver to reset some state when a new track
> starts.

OK.

Thanks,
Fengguang