Hans Verkuil wrote:
> On Friday 22 February 2008 03:12:45 Andy Walls wrote:
> > I ran a little experiment with blocking reads (like cat or mplayer
> > perform) to see exactly how well the cx18 driver driving my HVR-1600
> > 74041 LF responds to constant requests for data compared to the ivtv
> > driver driving my PVR-150MCE.
> >
> > The result is that the ivtv and PVR-150MCE have one outlier delay at
> > startup and then some consistent delay "quanta". The cx18 driver has
> > some consistent delay "quanta" as well, but also outlier delays that
> > occur often.
>
> What sort of values do you get? For cx18 the maximum value I get is
> around 0.1 second, which is perfectly OK. Yes, it is a bit higher
> compared to ivtv, but that doesn't really surprise me given the fact
> that the DMA engine is completely different. The timeout in MythTV is
> as far as I can see set at 5 seconds, which is WAY higher than the
> worst delay in cx18.
Worst case lengths of blocking reads by "cat /dev/video1" are....
$ cat cx18-intervals-* | sort -n | tail -n 20
0.105588
0.105622
0.106012
0.106312
0.107849
0.108349
0.109017
0.113372
0.118936
0.135646
0.139930
0.172767
0.315618
0.316282
0.919977
0.920489
0.922951
0.933520
1.642253
1.954469
And the very worst ones only happen very early on, usually on the second read():
$ grep -n '^[01]\.[^01]' cx18-intervals-*
cx18-intervals-autolock-nopalm-strong:2:0.922951
cx18-intervals-autolock-nopalm-weak:2:0.919977
cx18-intervals-autolock-strong:2:0.933520
cx18-intervals-autolock-weak:2:0.920489
cx18-intervals-autolock-weak:27:1.954469
cx18-intervals-strong:2:0.315618
cx18-intervals-weak:2:0.316282
cx18-intervals-weak:36:1.642253
I agree they shouldn't matter compared to the MythTV select() timeout.
I also suspect these shouldn't really matter if they occur infrequently.
But at 30 frames per second, 0.1 seconds is 3 frame times. How many
frames are encoded in a 4096 byte read from the cx18 driver? More than 3
I hope?
What I noticed/believed/assumed was that too many of these longer delays
made a perceptible difference (to me anyway) with an unbuffered
"mplayer /dev/video1".
I used the blocking read measurements for an *objective* measure to
compare the baseline, ivtv/pvr150, with my cx18/hvr-1600, and an
*objective* measure so that I could see if changes I made to the cx18
driver made things better or worse. I hate trying to make subjective
evaluations.
I will send you the data that I collected for various 5 minute test runs
and you can look at them in your favorite data analysis or visualization
program.
> I did some more detailed debugging and it is clear that the interrupts
> simply arrive a bit more erratic than with ivtv, but this is only the
> case for MPEG streaming: PCM and YUV streaming is perfectly regular. It
> might well be that the firmware combines small frames before outputting
> them, which would lead to a correct stream but somewhat erratic
> interrupt behavior.
I never tested the YUV or PCM streams.
What I empirically found with the MPEG stream is that TV signal quality
(SNR) from my antenna & amplifier setup affected how frequently this
longer delay on blocking reads occurred.
I found a contributing factor to erratic MPEG encoder irq rate: chroma
subcarrier tracking pull out with a poor signal due to always using the
fast convergence mode of the firmware.
I found that changing the setup of the apparent cx25840/1/2/3 core in
the cx23418 from "manual, fast chroma subcarrier lock" to "automatic
chroma subcarrier lock rate" produced a noticeable reduction in the
number of long delays to complete blocking reads. This setting really
makes things much better for me. I always plan to apply the below patch
in my copy of the driver, if it never formally makes it in.
Thanks for the good work and support. (I decided to buy my Hauppauge!
HVR-1600 product specifically because of your efforts.)
Regards,
Andy
--- cx18-03d4d8d84c4f/linux/drivers/media/video/cx18/cx18-av-core.c.orig
2008-02-23 18:51:52.000000000 -0500
+++ cx18-03d4d8d84c4f/linux/drivers/media/video/cx18/cx18-av-core.c
2008-02-23 22:51:05.000000000 -0500
@@ -126,9 +126,9 @@ static void cx18_av_initialize(struct cx
cx18_av_write4(cx, CXADEC_SOFT_RST_CTRL, 0);
/* set video to auto-detect */
- /* Clear bits 11-12 to enable slow locking mode. Set autodetect mode */
- /* set the comb notch = 1 */
- cx18_av_and_or4(cx, CXADEC_MODE_CTRL, 0xFFF7E7F0, 0x02040800);
+ /* Clear bit 11 and set bit 12 for auto-rate subcarrier locking */
+ /* set the comb notch fallback to 1, notch data is all chroma w/o luma*/
+ cx18_av_and_or4(cx, CXADEC_MODE_CTRL, 0xFCF3E7F0, 0x02041000);
/* Enable wtw_en in CRUSH_CTRL (Set bit 22) */
/* Enable maj_sel in CRUSH_CTRL (Set bit 20) */
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
