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

[David Härdeman]

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.

>> 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?

>> 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).

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.

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.

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.

Regards,
David