On Sun, 2008-02-24 at 00:16 -0500, Andy Walls wrote: > 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? > > Tried it but it didn't seem to make any difference where myth is involved. The cx18 works fairly well iff I buffer it for a bit (ie fire it to a file and then mplayer the file). I can also mplayer /dev/video1, pause for a couple sec, unpause and it also seems ok. I have to do the same time for /dev/video0(pvr250) in mplayer However myth always has the select timeout on the HVR1600 (about every 50 seconds it does it twice.) I also tried the strace cat /dev/video and can fire you the data if you wish > > -Andy > > > > > > > > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
