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.
I haven't dared to seriously try to combine OSD writing with MPEG playback (decoder operation) - as soon as I do (under 0.3.2b) writing to the OSD slows down to 1 frame per 60ms (i.e. a new frame every 3 video fields) which is useless for my purposes.
> In fact, I have yet to find someone else
online using a newer ivtv successfully with a new PVR-350.
Hm, my development PVR-350 is fairly old (April 2004?), but I've seen 0.3.2b running well on brand new ones on Intel reference motherboards for decoding & OSD - albeit admittedly with an 800MHz FSB on ~3GHz P4's. I haven't tried encoding or passthru yet. I can well believe that VIA chipsets or older motherboards might have issues with the DMA voodoo going on, however.
> 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.
Well, 0.3 is still very much in development, but it seems to me as if Chris Kennedy is/was onto something by DMAing the OSD directly to the card's DMA registers rather than using the card's firmware API to control things (if I understand what's going on correctly). I'm sure that stability issues will be overcome, if nothing else because it's easier to debug & tweak the new code than relying on the firmware to Do The Right Thing(tm).
Meanwhile,
On Mon, 14 Feb 2005 10:14:55 +0000, Matthew Hodgson <[EMAIL PROTECTED]> wrote:
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
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
I've managed to work around this by noticing and using the new IVTVFB_IOCTL_PREP_FRAME_BUF ioctl which CK added somewhere in 0.3. When using this to DMA to the OSD framebuffer, the timings are not affected by whether the decoder has been fired up this session, and I can reliably transfer frames at faster to realtime, other than the occasional frame being slightly delayed presumably due to some quirk of the kernel's scheduler. I'm going to try shifting the wait-for-vsync closer to the pci_dma_sync_single() in case the task is somehow preempted between the wait-for-sync and doing the actual DMA.
Thanks to everyone who took time to read my plea - and especially thanks to CK for implementing the IVTVFB_IOCTL_PREP_FRAME_BUF ioctl. Hopefully I'll eventually understand sufficient of the design to be able to contribute in some way other than trial and error fiddlings :/
M.
--
______________________________________________________________
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
