On Tue, 2008-11-25 at 17:22 -0500, igloocentral hotmail wrote: > Hi guys, I have been reading the threads here with interest since I am > also experiencing what looks like the same problem on my mythtv setup. > When watching Live TV captured from the HVR-1600 S-video input I get > brief pauses that occur every few seconds which the mythfrontend logs > as "NVP: prebuffering pause". The mythtv wiki lists a number of > possible explanations, none of which seem to apply since the error > does not occur using the tuner input. From what I gather in the > threads here, it is more likely that this message is telling me that > mythtv is buffering the video stream but still coming up short since > cx18 can't get enough system priority to get all the frames from the > capture card. Forgive me for mangling a complex technical issue into > newbie speak.
> Does this sound right? Well, it's a hypothesis, but it needs evidence to be supported or refuted. I have never been happy with the unbuffered performance of the CX23418 on linux. I've got some ideas on how to get a smoother rate of transfer from the encoder, but nothing done right now. > I can run further tests as directed. Do some testing with mplayer instead of MythTV. Just to eliminate any MythTV induced problems. Maybe something like this: $ su - root # service mythbackend stop # echo 15 > /sys/module/cx18/parameters/debug # exit $ v4l2-ctl -i 1 $ mplayer /dev/video0 -cache 16384 $ mplayer /dev/video0 Mplayer's status line will show something like this: A: 22.3 V: 22.3 A-V: 0.001 ct: 0.074 662/662 10% 2% 0.6% 0 0 15% A: is the audio timestamp decoded in seconds V: is the video timestamp decoded in seconds A-V: is the difference of the above The percentage at the end of the line is the % mplayer cache full One of the zeros before that is dropped frames. The 662/662 refers to the number of frames. You might want to get a feel for: How rapidly does the A-V difference grow with unbuffered playback? With buffered playback, how rapidly does the cache fill sink to 0%? With those debug settings I mentioned above, how often in the log to you get the "Possibly falling behind" messages and messages about putting buffers back into rotation? > To get my setup to boot I had to add vmalloc=192M pci=nommconf to my > grub kernel line. This resolved an apparent conflict between the > nVidia and Hauppauge cards. I tried the Hauppauge card in a different > slot which had no effect. I have documented this in my system > configuration: > http://mythtv.org/wiki/index.php/User:Ubamu#Hauppauge_HVR-1600 > > I have also tried the latest cx18-bugfix 1.0.3 as detailed below. > Thanks for your hard work on this driver and any tips you can > offer. /d > > $ dmesg | grep cx18 > [ 8.604266] cx18: Start initialization, version 1.0.3 > [ 8.604549] cx18-0: Initializing card #0 > [ 8.604550] cx18-0: Autodetected Hauppauge card > [ 8.604561] cx18 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -> > IRQ 16 > [ 8.605407] cx18-0: cx23418 revision 01010000 (B) > [ 8.825905] cx18-0: Autodetected Hauppauge HVR-1600 > [ 8.825907] cx18-0: VBI is not yet supported > [ 9.242552] tuner 1-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) > [ 9.242566] cs5345 0-004c: chip found @ 0x98 (cx18 i2c driver #0-0) > [ 9.276538] cx18-0: Disabled encoder IDX device > [ 9.276611] cx18-0: Registered device video0 for encoder MPEG (2 > MB) > [ 9.276614] DVB: registering new adapter (cx18) > [ 9.340942] cx18-0: DVB Frontend registered > [ 9.340963] cx18-0: Registered device video32 for encoder YUV (2 > MB) > [ 9.340982] cx18-0: Registered device video24 for encoder PCM audio > (1 MB) > [ 9.340984] cx18-0: Initialized card #0: Hauppauge HVR-1600 > [ 9.340996] cx18: End initialization > [ 45.552149] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 > (141200 bytes) > [ 46.161835] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 > bytes) > [ 46.167973] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) > [ 47.448956] cx18-0: loaded v4l-cx23418-dig.fw firmware (16382 > bytes) > $ grep cx18 /proc/interrupts > 16: 128493 129552 IO-APIC-fasteoi uhci_hcd:usb1, > pata_marvell, cx18-0, nvidia Since the cx18 driver is sharing an interrupt with a pata interface, I wouldn't worry too much about that, since that's probably an optical disc that isn't in heavy use (but the desktop/hal still polls it). I would think that sharing an interrupt with the nvidia hardware/driver is not what you want to do. Maybe changing to a slot that doesn't use that PCI IRQ line would help. Note slots 4 and slot 5 in a chassis may not rotate the interrupt line traces on the motherboard, so changing between those slots won't help. > 2008-11-25 13:50:46.190 NVP: prebuffering pause > 2008-11-25 13:51:00.450 NVP: prebuffering pause > 2008-11-25 13:51:15.960 NVP: prebuffering pause > 2008-11-25 13:51:29.937 NVP: prebuffering pause > 2008-11-25 13:51:36.685 NVP: prebuffering pause > 2008-11-25 13:51:38.850 NVP: prebuffering pause > 2008-11-25 13:51:45.280 NVP: prebuffering pause > 2008-11-25 13:51:56.609 NVP: prebuffering pause > 2008-11-25 13:52:09.220 NVP: prebuffering pause > 2008-11-25 13:52:18.599 NVP: prebuffering pause > 2008-11-25 13:52:21.998 NVP: prebuffering pause > 2008-11-25 13:52:33.309 NVP: prebuffering pause > 2008-11-25 13:52:44.538 NVP: prebuffering pause > 2008-11-25 13:52:56.116 NVP: prebuffering pause > 2008-11-25 13:53:01.764 NVP: prebuffering pause These indicate underruns from the cx18 driver of some sort. In my experience the encoder doesn't yield buffers at a uniform rate over short time periods. Alternately your system could be missing the CX23418 firmware's latency requirement for responding to interrupts to pick up buffers. The debug messages that the cx18 driver emits can give me a clue as to which it is. To solve the first problem I'd need to write a change to allow users to tune the size of the buffers we give the encoder (smaller buffers make it hand them back to us faster/more regularly). To solve the second problem I'd have to implement a polled mailbox IO change in the driver. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
