On Wed, 2009-12-02 at 18:47 +0100, Martin Dauskardt wrote:
> > Date: Mon, 30 Nov 2009 20:03:02 -0500
> > From: Andy Walls <[email protected]>
>
>
> > I suspect that these signals floating cause the CX23416 to make some bad
> > guesses about audio sample rate when CX2341X_ENC_INTIALIZE_INPUT is
> > called. The only note I have about INITIALIZE_INPUT is that it is for
> > video input initialization.
> >
> > I don't know the history here, but on the surface your patch looks
> > plausible that it would solve the problem. I just don't know about the
> > applicability to other CX2584x/CX23416 boards other then the PVR-150;
> > the patch might apply to them too.
> >
>
> This area around CX2341X_ENC_INTIALIZE_INPUT is critical code which Hans made
> stable after a lot of testing:
>
> http://www.gossamer-threads.com/lists/ivtv/devel/36272
> http://linuxtv.org/hg/v4l-dvb/rev/904736fc862a
>
> Summary:
> The CX2341X_ENC_INITIALIZE_INPUT firmware call should be made whenever the
> digitizer (saa7115 or cx25840) has changed, either because the TV standard
> was
> changed, another input was chosen (or opening the radio device) or the video
> format changes (e.g. capture size, VBI settings). But it turned out that the
> digitizer has to be turned off before calling this API and turned on
> afterwards. This is definitely the case for the saa7115, the cx25840 seems to
> be more forgiving.
Martin,
Thanks for the pointer to the messages.
So this is a tough choice.
1. The fix to leave the CX2584x pins enabled *may occasionally* hang
people's machines, according to those results of Hans. :(
or
2. Floating CX2584x -> CX23416 clock pins will almost certainly result
in tinny audio.
> I remember that the 300ms ivtv_msleep_timeout was absolutely necessary to
> avoid occasionally black video after starting the capture. (I don't know if
> this is related to the digitizer calls or if we simply need this time to
> allow
> execution of the previous encoder commands before calling
> CX2341X_ENC_INITIALIZE_INPUT.)
It is probably needed for the clock output of the digitizer to
stabilize.
Argus,
Here's the patch I'm ready to apply to the latest ivtv driver, but could
you do more extensive testing - starting and stopping captures - to make
sure your machine never hangs with your fix.
diff -r e0cd9a337600 linux/drivers/media/video/ivtv/ivtv-streams.c
--- a/linux/drivers/media/video/ivtv/ivtv-streams.c Sun Nov 29 12:08:02
2009 -0200
+++ b/linux/drivers/media/video/ivtv/ivtv-streams.c Wed Dec 02 20:31:43
2009 -0500
@@ -576,10 +576,16 @@
clear_bit(IVTV_F_I_EOS, &itv->i_flags);
/* Initialize Digitizer for Capture */
- v4l2_subdev_call(itv->sd_video, video, s_stream, 0);
+ if (itv->sd_video->grp_id & IVTV_HW_CX25840)
+ v4l2_subdev_call(itv->sd_video, video, s_stream, 1);
+ else
+ v4l2_subdev_call(itv->sd_video, video, s_stream, 0);
ivtv_msleep_timeout(300, 1);
+
ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
- v4l2_subdev_call(itv->sd_video, video, s_stream, 1);
+
+ if (!(itv->sd_video->grp_id & IVTV_HW_CX25840))
+ v4l2_subdev_call(itv->sd_video, video, s_stream, 1);
}
/* begin_capture */
> @ ivtv at moasat:
> This is the first time that I read about tinny audio with a PVR350. Are you
> sure that this card has the same problem?
>
> If it comes out that the tinny audio is related to cx25840 only, and that
> these digitizer does not need to be turned off, than a modified code should
> check for itv->hw_flags & IVTV_HW_CX25840 instead of board names.
>
> BTW: For the pvrinput vdr plugin I am using the encoder stop/start ioctls for
> every channel switch (to clear the encoder). While the whole process of
> stopping, tuning and starting is very fast with a PVR250/350, it takes nearly
> a second longer with PVR150. Maybe turning the cx25840 off and on takes
> longer
> than with saa7115.
There are 2 I2C register wrties to the CX2584x, for every 1 I2C register
write to the SAA7115.
Regards,
Andy
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
