[Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
fengguang.wu at intel.com
Tue Nov 3 06:09:39 PST 2009
On Tue, Nov 03, 2009 at 09:16:37PM +0800, David Härdeman wrote:
> I've done some more testing...
That's awesome efforts, thank you very much!
> I managed to borrow a DG45FC based computer with Windows 7 (32-bit, using
> HDMI driver 14.6 from Intel's website) from a colleague over the weekend.
> Under Windows 7, HDMI audio with my receiver just works when using the
> Windows drivers (no complete-track-silence, no initial 0.5s silence). If I
> use the control panel application to configure a 5.1 speaker setup, the
> corresponding 5.1 speaker indication lights up on the receiver LCD and
> stays on whether I'm playing stereo sounds (like Windows event sounds) or
> multi-channel sources (tested with a DVD played using VLC with software
> decoding of the AC3 track to 6 channel PCM stream). This suggests that my
> issues *can* be resolved by hacking the driver :)
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)
> 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 22.214.171.124 of the HDA spec).
Yeah, it's interesting to have some "SilentStream":
V (Validity): This bit affects the "Validity flag," bit
transmitted in each subframe, and enables the S/PDIF
transmitter to maintain connection during error or mute
> 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).
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.
> Perhaps I've been going down the wrong path by focusing too much on the
> audio infoframe side of things.
> I wonder if the approach taken by the Windows drivers when there is
> nothing to play is more similar to the pause/play commands in the Linux
> driver and if it would be a big undertaking to make the Linux driver do
> something similar...?
Maybe. I wonder if there is some _windows_ tool to query the audio
> (Another option I'm planning to look into is whether power-saving might
> interfere with normal HDMI audio operation.)
One known problem is, the Xorg DPMS ops can mute HDMI audio..
> On Mon, November 2, 2009 09:57, Wu Fengguang wrote:
> > FYI, I worked up a patchset which incorporates your patch
> > and plan to submit it some time later. Tests OK on my side :)
> Which kernel version is the patchset based on? I couldn't apply it to
> 2.6.32-rc5 or git head (which is what I've been using for your previous
It's based on sound-2.6:
More information about the Intel-gfx