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 raw1394's restriction. 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.) -- Stefan Richter -=====-==--- -==- -==== http://arcgraph.de/sr/
