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

[Wu Fengguang]

On Thu, Oct 29, 2009 at 06:46:26PM +0800, David Härdeman wrote:
> On Thu, October 29, 2009 10:46, Wu Fengguang wrote:
> > On Thu, Oct 29, 2009 at 04:16:21PM +0800, David wrote:
> >> 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).
> 
> Can't AC_VERB_GET_PIN_SENSE be used at module load time to get the initial
> state of sink_present?

Good idea, thanks!

> >> However, I still have the silence (on track change) problem.
> >
> > //tea you
> 
> Which means? :)

Have a cup of tea :)

> >> If the msleep() you suggested fixes the silence during the first 0.5s
> >
> > They are two logically different problems?
> 
> Sorry, I was being vague. What I meant was that if sticky-infoframe was
> necessary to fix the 0.5s initial silence problem then it wouldn't be
> possible to also do a CC=0 (not CT as I said) infoframe fix. But if the
> 0.5s silence can be fixed using msleep then it will still be possible to
> experiment with CC=0 infoframes when the audio device is not used.

Yeah, OK.

> >> 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.
> 
> Yes.
> 
> > I'm not sure why your device can silence even nothing changed with the
> > infoframe.
> 
> I'm not sure either - worst case, the receiver has a buggy HDMI
> implementation (yay!).
> 
> > 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.
> 
> I'll try to find time to test your patch this evening.
> 
> >> Also, are you sure that the checksum is really supposed to be in the DIP
> >> buffer?
> >
> > OK I'll ask. The test (you can confirm that easily with the additional
> > patch) does not quite agree with the spec :(
> 
> In the meantime I'll do some more testing with/without checksums...

Thanks.

FYI, I worked up a patchset which incorporates your patch
and plan to submit it some time later.  Tests OK on my side :)

Thanks,
Fengguang

-------------- next part --------------
A non-text attachment was scrubbed...
Name: intel-hdmi-2009-11-02.tgz
Type: application/x-gtar
Size: 6627 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20091102/cda19078/attachment.gtar>