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

[David Härdeman]

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?

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

Which means? :)

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

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

Regards,
David