Mailing List Archive: ivtv: devel

IVTVFB_IOCTL_PREP_FRAME's timings fluctuate after DMAing to the decoder.

Index | Next | Previous | View Threaded

matthew at mxtelecom

Feb 14, 2005, 3:14 AM

Post #1 of 4 (696 views)
Permalink

IVTVFB_IOCTL_PREP_FRAME's timings fluctuate after DMAing to the decoder.

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 matthew [at] mxtelecom 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
ivtv-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

mavantix at gmail

Feb 14, 2005, 4:33 AM

Post #2 of 4 (677 views)
Permalink

Re: IVTVFB_IOCTL_PREP_FRAME's timings fluctuate after DMAing to the decoder. [In reply to]

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
<matthew [at] mxtelecom> 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 matthew [at] mxtelecom 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
> ivtv-devel [at] lists
> 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
ivtv-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

matthew at mxtelecom

Feb 14, 2005, 6:12 AM

Post #3 of 4 (684 views)
Permalink

Re: RESOLVED: IVTVFB_IOCTL_PREP_FRAME's timings fluctuate after DMAing to the decoder. [In reply to]

Maverick wrote:
> 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
> <matthew [at] mxtelecom> 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 matthew [at] mxtelecom 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
ivtv-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

matthew at mxtelecom

Mar 23, 2005, 6:31 AM

Post #4 of 4 (683 views)
Permalink

Re: UNRESOLVED: IVTVFB_IOCTL_PREP_FRAME's timings fluctuate after DMAing to the decoder. [In reply to]

>> On Mon, 14 Feb 2005 10:14:55 +0000, Matthew Hodgson
>> <matthew [at] mxtelecom> 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,

(this should of course have said /dev/video16 in my original mail)

>>> 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.

Unfortunately, in 0.3.2[ijk], this no longer works - after having been
writing some mpeg to /dev/video16, trying to write to the OSD using
IVTVFB_IOCTL_PREP_FRAME_BUF transfers at ~80% of the speed it did before
(and with more fluctuation in the timings).

Using PREP_FRAME_BUF did solve this behaviour with 0.3.2b, other than after
a few days "ivtv: DEC 1st DMA Xfer Info failed=0xfffffff0 336827317" style
errors would surface on the first few writes to the OSD after having been
playing MPEG (or vice versa). After a bit longer, DMAs to the OSD became
unstable altogether, which is why I'm trying to upgrade to a 0.3.2 with
cleaner DMA code.

To demonstrate the problem with 0.3.2k:

# modprobe ivtv
# modprobe ivtv-fb
# ./ivtvfbctl /dev/fb0 -prepdma -nosleep
...
frameloop: userspace buffer 0xb7cfe000 of 1658880 bytes:
Warning, you must change CPU_HZ to be accurate, currently 2793423000:
mlock rc = 0
iter 0: time = 33.058521 fps
iter 1: time = 32.919242 fps
iter 2: time = 32.929567 fps
iter 3: time = 32.971597 fps
iter 4: time = 32.975228 fps
iter 5: time = 32.957011 fps
iter 6: time = 32.931189 fps
iter 7: time = 32.912909 fps
iter 8: time = 32.951270 fps
iter 9: time = 32.959177 fps
iter 10: time = 32.971320 fps
iter 11: time = 32.879614 fps
iter 12: time = 32.961221 fps
iter 13: time = 32.964796 fps
etc.

# cat test.mpeg > /dev/video16

# ./ivtvfbctl /dev/fb0 -prepdma -nosleep
...
frameloop: userspace buffer 0xb7cfe000 of 1658880 bytes:
Warning, you must change CPU_HZ to be accurate, currently 2793423000:
mlock rc = 0
iter 0: time = 24.887542 fps
iter 1: time = 25.405616 fps
iter 2: time = 25.393173 fps
iter 3: time = 24.822726 fps
iter 4: time = 25.403095 fps
iter 5: time = 25.428180 fps
iter 6: time = 24.811362 fps
iter 7: time = 25.425392 fps
iter 8: time = 25.419839 fps
iter 9: time = 25.420931 fps
iter 10: time = 25.448121 fps
iter 11: time = 25.393103 fps
iter 12: time = 25.404537 fps
etc.

Can anyone else reproduce this simple test case?

Does anyone have any idea why it happens, and/or how to stop it?

thanks;

Matthew.

--
______________________________________________________________
Matthew Hodgson matthew [at] mxtelecom Tel: +44 845 6667778
Systems Analyst, MX Telecom Ltd.

-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] lists
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads