Dropped frames can happy for a variety of reasons:
1. Your app is getting behind and the ring buffer fills.
2. The bits get corrupted on the bus (since it's isochronous there is no
3. Traffic on your PCI bus cause the DMA transfer to get delayed and a
packet is dropped when the firewire chipset's FIFO fills (such FIFOs are
generally around 4-8kB in size).
Your case sounds like probably 1 or 3. It's pretty easy to determine if
1 is happening. Just print the frame's timestamp and the system clock
when you dequeue the packet. If they diverge by more than N*t, where N
is the size of the ring buffer and t is the nominal time between frames,
you are almost certainly dropping frames.
Given that changing the ring buffer size had no effect, you probably
have situation 3 -- in which case there's really nothing you can do
about it, except get a faster computer or a different firewire chipset.
If you want to instrument what's happening at a detailed level, look at
the function callback() in dc1394/macosx/capture.c. It is called
asynchronously whenever a full frame is received: The interrupt fires,
and that turns into a notification that wakes up the run loop of that
thread, and then callback() is called.
You can create a new callback, and call it for _every_ packet instead of
just once per frame. You'll have to modify CreateDCLProgram() so that a
callback is added to every DCL with SetDCLCallback, instead of just the
last DCL per frame.
I would advise against dequeue() and enqueue() in separate threads. It
might work, but it would depend on certain Mac OS X firewire functions
being thread-safe, and I'm not certain they are. Besides, the run loop
for handling new frames is already a separate thread anyway in libdc1394
for Mac OS X.
On Wed, 2007-01-24 at 18:58 +0100, Mark Munte wrote:
> under certain circumstances my app loses some frames - e.g. when the =20
> user activates Expos=C3=A9'.
> I don't really understand what is the cause of the dropped frames.
> I am using DMA capture under OS X. I tried several ring buffer sizes =20
> (from 2 to 40) but that does not solve the problem.
> Is it correct that using DMA capture means the DMA function gets =20
> called at interrupt time?
> If that is so, the only reason I could get dropped frames, is the =20
> ring buffer is full. Or might there be something else going wrong?
> I am thinking if it would be a good idea to separate capturing and =20
> processing of the captured data into two separate threads.
> Can I call dc1394_capture_dequeue from one thread and =20
> dc1394_capture_enqueue from another.
> Would that make sense - I would appreciate some thought's on that.
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share=
> opinions on IT & business topics through brief surveys - and earn cash
> Mailing list for libdc1394-devel