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
Attachment:
intel-hdmi-2009-11-02.tgz
Description: GNU Unix tar archive
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
