on patch "DVB: add firesat driver" in staging.git
stefanr at s5r6.in-berlin.de
Sun Jun 15 15:39:37 UTC 2008
Robert Berger wrote:
> Andreas Monitzer wrote:
>> On Jun 15, 2008, at 00:16, Stefan Richter wrote:
>>> I forgot: There is also the more fundamental question whether all of
>>> this shouldn't rather be done in userspace, like with FireWire set
>>> top boxes that are commonly used in North America. But I am unable
>>> to assess this due to lack of knowledge of the DVB side.
>> The DVB API assumes that devices are handled by kernel modules, that's
>> why I created one in the first place.
OK. IOW the benefit is that FireWire DVB cards are presented to
userspace like any other DVB card.
>> Additionally, there are performance considerations that have to be
>> taken into account (receiving the stream has to happen in realtime,
>> otherwise the video and audio streams would stutter), so this might
>> pose another need for a kernel module (I don't know enough about the
>> raw1394 API to judge that, though).
I am not familiar with isochronous 1394 application programming at all.
But IIDC (uncompressed video for machine vision, surveillance etc.), DV
(compressed video with camcorders, TVs, STBs), and semipro/pro audio are
all handled in userspace, which is evidence that many realtime
requirements can be satisfied with userspace implementations.
AFAIU zero-copy operation is possible with raw1394 only within the
constraints of a ring buffer of programmable size. This buffer is to be
used during the whole reception, which makes zero-copy unrealistic in
most situations. I don't know about the capabilities of video1394,
which is another userspace ABI of the ieee1394 stack. The new firewire
stack's firewire-cdev ABI allows for zero-copy operation without
However, zero-copy operation is not a general requirement for realtime
applications, although it is of course desirable, or actually necessary
on resource restricted hardware.
> I don't know enough about the 1394 API to judge for this project, but I
> believe that there are similarities to IPTV systems, where the streams
> are coming through an Ethernet interface.
> Some people want to avoid the copy from kernel to user space (network
> stack) and back to kernel space (inject into some hardware demux) in
> case of a user space application, hence they go for the kernel space
> implementation and claim it's for performance reasons, but I do have
> evidence, that it's not enough. (different implementations on the same
> hardware platform)
> In case you receive some RTP stream over the network you need to peel
> off various headers and stuff like layers from an onion to end up with
> the raw data, which can be injected into the demux.
> Do you see similarities for the 1394 stuff?
AFAIK raw1394 uses a feature of FireWire controllers which discards IEEE
1394 headers from received streams before DMA. The new firewire-cdev
API uses a more flexible feature, dual buffer DMA, which lets the
controller write headers of configurable size (i.e. IEEE 1394 headers
and optionally additional format-dependent headers) into a buffer
separate from the payload buffer.
(Note though that I have no expertise in any of these areas. Some
people over at linux1394-devel have, but I didn't want to cross-post.)
-=====-==--- -==- -====
More information about the devel