Just a casual observation on my part, I've found the DMA stuff in the newer drivers (the ones that support my new PVR-350) to be really flaky. A certian combination of framebuffer writes/video playback definitely goes haywire. In fact, I have yet to find someone else online using a newer ivtv successfully with a new PVR-350. I've seen various comments blaming APIC and VIA Chipset motherboards for having faulty DMA buses, but I'm still thinking something is whack in ivtv. I don't have a VIA Chipset based motherboard. Not that that's any help thought, wish I could be more informative.
-Kenneth On Mon, 14 Feb 2005 10:14:55 +0000, Matthew Hodgson <[EMAIL PROTECTED]> wrote: > Hi all, > > On using IVTVFB_IOCTL_PREP_FRAME to write to my PVR-350's OSD immediately > after loading the modules, I can reliably copy a full PAL frame in about 85% > of the 40ms time window available: > > frame #1: time 0.82442500 frames, average 0.82442500 > frame #2: time 0.82477500 frames, average 0.82460000 > frame #3: time 0.82477500 frames, average 0.82465833 > frame #4: time 0.82475000 frames, average 0.82468125 > frame #5: time 0.84977500 frames, average 0.82970000 > frame #6: time 0.84975000 frames, average 0.83304167 > frame #7: time 0.84972500 frames, average 0.83542500 > frame #8: time 0.84977500 frames, average 0.83721875 > frame #9: time 0.84975000 frames, average 0.83861111 > > (times expressed as fractions of a 40ms realtime 'frame'). > > This is great, as I can write to the OSD and then wait for vsync in the > remaining 15% and so largely eliminate tearing. > > However, if I then fade the OSD and write some MPEG to /dev/video0, > afterwards on writing to the OSD again the timings are all over the place - > and mostly take longer than 40ms to transfer the frame, meaning I can no > longer framesync or play back in realtime: > > time 0.84977500 frames, average 0.97740833 > time 1.09965000 frames, average 0.98963250 > time 1.09970000 frames, average 0.99963864 > time 0.84975000 frames, average 0.98714792 > time 1.09972500 frames, average 0.99580769 > time 0.84975000 frames, average 0.98537500 > time 1.09975000 frames, average 0.99300000 > time 1.09967500 frames, average 0.99966719 > time 0.87475000 frames, average 0.99231912 > time 0.87477500 frames, average 0.98578889 > time 1.12470000 frames, average 0.99310000 > time 1.12467500 frames, average 0.99967875 > > This only appears to happen after the 16 decoder DMA buffers have been > filled, v4l2_decode is called, and the dec_work_handler kthread starts to > process DMA requests from the decoder. If I skip out of the > dec_work_handler before it gets too far into setting up the DMA then this > doesn't happen (but obviously video playback doesn't work either ;) Turning > decoder prebuffering on & off doesn't seem to affect it. Doing a sysrq dump > of the kernel state before & after using the decoder shows the various > kernel tasks to be in identical state. The IRQ mask before & after is the > same. All the setup that start_v4l2_decode and stop_v4l2_decode do doesn't > trigger the behaviour - unless, of course, data actually starts to be DMA'd. > > This behaviour presents itself using both 0.2 and 0.3 drivers, and all the > different firmwares I have at my disposal. In 0.3 the effect is more > obvious if you remove the wait-for-vsync in ivtvfb_ioctl_prep_frame. The > hardware in question is a 2.8GHz Pentium 4. > > I'm pretty much completely stumped by this - any help would be greatly > appreciated, (even if it's just to say that this is a 'feature' of the > Hauppauge firmware :/ ) > > thanks, > > Matthew. > > -- > ______________________________________________________________ > Matthew Hodgson [EMAIL PROTECTED] Tel: +44 845 6667778 > Systems Analyst, MX Telecom Ltd. > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
