[Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
david at hardeman.nu
Thu Oct 29 03:46:26 PDT 2009
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
>> if (spec->sink_present[i] != true)
>> 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
>> 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
>> 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
I'm not sure either - worst case, the receiver has a buggy HDMI
> 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
> 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...
More information about the Intel-gfx