Wed Nov 4 02:15:32 PST 2009
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
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
More information about the Intel-gfx