All,

When comparing ivtv/PVR-150mce performance with cx18/HVR-1600
performance, I noticed the two bahved differently for strong and weak
over the air NTSC signals.

Using ivtv-tune to switch between a strong (high SNR) and weak (low SNR)
ABC affiliate broadcasting the same program, I noted a difference in the
output of v4l2-ctl --log-status

$ ivtv-tune -d /dev/video0 -c 7
$ v4l2-ctl  -d /dev/video0 --log-status

   cx25840 0-0044: Detected format:           NTSC-M
   cx25840 0-0044: Specified standard:        NTSC-M
   cx25840 0-0044: Specified video input:     Composite 7
   cx25840 0-0044: Specified audioclock freq: 48000 Hz
   cx25840 0-0044: Detected audio mode:       stereo with SAP
   cx25840 0-0044: Detected audio standard:   BTSC
   cx25840 0-0044: Audio muted:               no
   cx25840 0-0044: Audio microcontroller:     running
   cx25840 0-0044: Configured audio standard: automatic detection
   cx25840 0-0044: Configured audio system:   BTSC
   cx25840 0-0044: Specified audio input:     Tuner (In8)
   cx25840 0-0044: Preferred audio mode:      stereo
   tuner 0-0061: Tuner mode:      analog TV
   tuner 0-0061: Frequency:       175.25 MHz


$ ivtv-tune -d /dev/video0 -c 8
$ v4l2-ctl  -d /dev/video0 --log-status
   cx25840 0-0044: Detected format:           NTSC-M
   cx25840 0-0044: Specified standard:        NTSC-M
   cx25840 0-0044: Specified video input:     Composite 7
   cx25840 0-0044: Specified audioclock freq: 48000 Hz
   cx25840 0-0044: Detected audio mode:       stereo
   cx25840 0-0044: Detected audio standard:   BTSC
   cx25840 0-0044: Audio muted:               no
   cx25840 0-0044: Audio microcontroller:     running
   cx25840 0-0044: Configured audio standard: automatic detection
   cx25840 0-0044: Configured audio system:   BTSC
   cx25840 0-0044: Specified audio input:     Tuner (In8)
   cx25840 0-0044: Preferred audio mode:      stereo
   tuner 0-0061: Tuner mode:      analog TV
   tuner 0-0061: Frequency:       181.25 MHz




$ ivtv-tune -d /dev/video1 -c 7
$ v4l2-ctl  -d /dev/video1 --log-status

   cx18-0: Detected format:           NTSC-M
   cx18-0: Specified standard:        NTSC-M  
   cx18-0: Specified video input:     Composite 7
   cx18-0: Specified audioclock freq: 48000 Hz
   cx18-0: Detected audio mode:       mono
   cx18-0: Detected audio standard:   BTSC
   cx18-0: Audio muted:               yes
   cx18-0: Audio microcontroller:     running
   cx18-0: Configured audio standard: automatic detection
   cx18-0: Configured audio system:   BTSC
   cx18-0: Specified audio input:     Tuner (In8)
   cx18-0: Preferred audio mode:      stereo
   tuner 2-0061: Tuner mode:      analog TV
   tuner 2-0061: Frequency:       175.25 MHz



$ ivtv-tune -d /dev/video1 -c 8
$ v4l2-ctl  -d /dev/video1 --log-status

   cx18-0: Detected format:           PAL-M
   cx18-0: Specified standard:        NTSC-M
   cx18-0: Specified video input:     Composite 7
   cx18-0: Specified audioclock freq: 48000 Hz
   cx18-0: Detected audio mode:       mono
   cx18-0: Detected audio standard:   BTSC
   cx18-0: Audio muted:               yes
   cx18-0: Audio microcontroller:     running
   cx18-0: Configured audio standard: automatic detection
   cx18-0: Configured audio system:   BTSC 
   cx18-0: Specified audio input:     Tuner (In8)
   cx18-0: Preferred audio mode:      stereo
   tuner 2-0061: Tuner mode:      analog TV
   tuner 2-0061: Frequency:       181.25 MHz



ivtv detects "stereo with SAP" for a strong signal, but only "stereo"
for a weak signal, but always detects NTSC-M and the audio is always
unmuted.

cx18 detects NTSC-M for a strong signal, but "PAL-M" for a weak signal,
and always mutes the audio (initially?) and detects "mono" audio, even
when stereo audio should be available.


I further researched the PAL-M detection, to see if turning off
autodetection of PAL-M (I'll never get a TV signal from Brazil) would
help the cx18 performance problem I've been experiencing.  When
researching this I found that the cx18 driver was turning on Manual,
Fast Chroma Subcarrier Lock and leaving it that way.  Since the steps
taken to setup the subcarrier lock in the driver didn't quite make
sense, and since there doesn't seem to be an attempt in the cx18 driver
to support fast channel switching, and since the difference between
NTSC-M and PAL-M is all about the chroma subcarrier, I experimented with
tweaking the chroma subcarrier locking as well.


My evaluation tools for my changes were MythTV, mplayer, and strace of
"cat /dev/video" as I mentioned in a previous e-mail but for a 5 minute
period of time.


My changes were to set the chroma subcarrier locking to auto lock speed
select (fast when unlocked, slow when locked) and then to additionally
force autodetection never to select PAL-M when it had to choose between
NTSC-M and PAL-M.


1. I found that allowing chroma subcarrier lock to auto made MythTV
worse.  Getting data out of the cx18 driver takes a little longer at
capture startup in this case (I think).  An unpatched MythTV will
timeout trying to select() on the device and then close it and reopen it
- starting the cycle of failure over again.

2. mplayer performance was noticably improved when setting auto chroma
subcarrier lock speed (you may need to push the keyboard up arrow in
mplayer shortly after startup though to resync due to startup delays).
Startup on weak TV signals took longer.  Forcing autodetection of NTSC-M
over PAL-M had a small degrading effect on the initial improvement.

3. tracing of blocking read() made by cat show a dramatic improvement in
the time spent blocked in a read with auto chroma subcarrier lock speed
turned on for weak signals and strong signals.  There are much fewer
"long blocking intervals" but still not as few as ivtv.  Forcing
autodetection of NTSC-M over PAL-M showed a small degradation of the
improvement.


So my findings were to:
a) turn off manual fast chroma subcarrier locking and use autorate
subcarrier locking in cx18
b) leave video standard autodetection the way it is for now in cx18
c) patch up MythTV to allow a few retries on select() timeouts after
just (re)opening a cx18 device node, before closing and reopening the
device node. (I need to test this.)


Attached is my patch for the cx18 driver.  When investigating, I noted
the cx23418 a/v digitizer registers looked the same as the
cx25840/1/2/3, so I assume that chip core is in the cx23418.  The
datasheet can be found at:

http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf



Anyone else want to try and see if this patch helps with cx18 for an
HVR-1600 74041?


-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,15 @@ 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*/
+	/* see the CX25840/1/2/3 data sheet for more details */
+	v = cx18_av_read4(cx, CXADEC_MODE_CTRL);
+	CX18_DEBUG_INFO("av_init: Video mode control register was %#010x\n", v);
+	/* XXX relying on firmware defaults with "and_or" isn't deterministic */
+	cx18_av_and_or4(cx, CXADEC_MODE_CTRL, 0xFCF3E7F0, 0x02041000);
+	v = cx18_av_read4(cx, CXADEC_MODE_CTRL);
+	CX18_DEBUG_INFO("av_init: Video mode control register is  %#010x\n", v);
 
 	/* 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

Reply via email to