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

Wu Fengguang fengguang.wu at intel.com
Thu Oct 29 10:46:02 CET 2009


Hi David,

On Thu, Oct 29, 2009 at 04:16:21PM +0800, David Härdeman wrote:
> On Wed, October 28, 2009 05:46, Wu Fengguang wrote:
> > - the checksum field cannot be removed - otherwise 8-channel audio
> >   will be played only as 2-channel.
> > - if add a 800ms sleep in intel_hdmi_playback_pcm_prepare(), the
> >   first-0.5s-samples-lost problem disappears
> >
> > Attached is the updated patchset.
> 
> Good morning,
> 
> I tried your latest patchset (2009-10-28) on top of 2.6.32-rc5.

Thanks.

> The first problem I came across was that in these lines from
> hdmi_setup_audio_infoframe:
> 
> 	if (spec->sink_present[i] != true)
> 		continue;
> 
> spec->sink_present[i] was always false for some reason (is sink_present
> only set as a result of HDMI hot-plug detection?) so I commented out those
> two lines for now.

Yes this is problematical if you are reloading the kernel module
instead of rebooting. Because sink_present will only be set on hotplug
events, and only one such event will be triggered at kernel boot time
(perhaps at i915 module init time).

> However, I still have the silence (on track change) problem.

//tea you

> If the msleep() you suggested fixes the silence during the first 0.5s

They are two logically different problems?

> problem, then perhaps it would be possible to change the infoframe code so
> that an audio infoframe with the ct bits set to zero is transmitted when
> the pcm device is not in use instead of using a sticky infoframe (which
> seems to fix it for me at least)?

The CC=0 infoframe is different from sticky infoframe in that, the
former solution has to stop/refill/restart infoframe on each playback.
I'm not sure why your device can silence even nothing changed with the
infoframe. Would you retry the attached patch and post the dmesg? This
is just to make things more clear. I'm not against your patch in general.

> Also, are you sure that the checksum is really supposed to be in the DIP
> buffer? The buffer hardware size seems odd if that is the case (since PB10
> will have to be discarded). Section 7.3.3.36 of HDA034-A2 and HDA036-A
> (which you referred to) both seem to suggest that the checksum byte should
> be excluded (which would make the hardware and software buffer sizes
> match). Could you perhaps get clarification on that point from someone at
> Intel?

OK I'll ask. The test (you can confirm that easily with the additional
patch) does not quite agree with the spec :(

Thanks,
Fengguang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hdmi-intel.patch
Type: text/x-diff
Size: 26945 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20091029/8b4e7615/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hdmi-remove-ai-checksum.patch
Type: text/x-diff
Size: 1864 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20091029/8b4e7615/attachment-0001.patch>


More information about the Intel-gfx mailing list