Re: [Alsa-user] [Intel-gfx] Problems with HDMI audio on Intel DG45FC motherboard
Brought to you by:
perex
From: David H. <da...@ha...> - 2009-10-29 10:46:44
|
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 |