[gst-devel] 1394(firewire) source added

[Dan Dennedy]

From: "Erik Walthinsen"
> Good.  The issue I ran into is a rather hard one, and hopefully it can be
> avoided in video1394:
>
> The call stack is something like:
>
> [dv]1394src_chain
> raw1394_loop_iterate
> [dv]1394src_iso_receive(size,data)
> buf = new_buffer(size,data);
> gst_pad_push(buf);
> (cothread switch to other element)
> (cothread switch back from element
> <
> <
> <
> <
>
> The problem is that the buffer constructed in [dv]1394src_iso_receive is
> built around the pointer on the iso_receive arg list.  This pointer is
> only valid until the end of the handler, afaict.  This means that if the

That sounds right, you need to memcpy to your own buffer or buffer queue.
This keeps the library from having to do messy memory management that may
not coincide well with an application's requirements.

> peer element doesn't finish with that buffer right then and there (i.e.
> wants to hold onto it for some short period of time in order to, say, go
> through N of them in one go), the pointer becomes invalid.
>
> Basically, I need to make sure that I can have arbitrary amounts of 1394
> data stored in RAM, as placed there directly by the subsystem, rather than
> forcing me to copy it myself into 'non-volatile RAM'.  If I understand the
> concept correctly, and it's implemented correctly, this is exactly what
> user-space DMA is all about.

Yes, you allocate the buffer space, and then mmap to the device's file
descriptor. Then, the DMA hardware dumps data directly into that space.

> That said, do you see any possibility for raw1394 have this capability any
> time soon?  Since raw1394 is the lowest level access you can get from

No, evidently, the "other" 1394 adaptor, pcilynx, does not support the DMA
feature. It has some sort of DMA onboard to control data reception and
transmission, but it does not conform to the OCHI standard for DMA
programming. So, I am not sure if the limitation is in the hardware or the
driver. If it's the driver, well, the only knowledgeable one is the pcilynx
maintainer who is also the libraw1394 maintainer.

> userspace, and there won't be random protocol driver modules in the kernel
> for a long time, it makes sense for raw1394 to have the same performance
> for dc1394 and sbp-2 (yes, I know that's done in kernel...) and other
> things like mLAN as a custom coded module.  I can't see any fundamental

I am not sure what you mean by random protocol driver modules. video1394 is
sort of like a random protocol driver because it just speaks isochronous
data whatever protocol it is. Furthermore, it is not even an officially
registered character device with an assigned major number, and it is
included with the kernel!

> reason in the raw1394 and driver code why that can't be done, but I didn't
> spend long looking.

There might also be a non-obvious reason such as simplicity--both for the
lib user and implementor. Why go messing around with libraw1394, raw1394,
and perhaps even the drivers ohci1394 and pcilynx? Keep in mind the
video4linux compliance is a good reason for the creation of the driver
modules, and I want to move some dc- and dv-specific stuff into their
respective drivers. My time is limited, and I know the approach I am taking
will work and has a greater chance of adoption.

> TIA,
>    Omega
>
>       Erik Walthinsen <omega at temple-baptist.com> - System Administrator
>         __
>        /  \                GStreamer - The only way to stream!
>       |    | M E G A        ***** http://gstreamer.net/ *****
>       _\  /_
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>