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. > > 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 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. So the classic approach is for each packet to allocate some memory for one layer and less for the next (stripped stuff) and less for the next and so on. To pass from one layer to the next you do some copies, which is very expensive in terms of performance. It turned out that it's worthwhile to write your own memory manager, which contains a reusable pool of chunks of memory. In order to pass form one to the next layer no copying is needed, but just some playing around with pointers. Like this a user space application with a memory manager can easily outperform a kernel space application, which does not use it's own memory manager. Of course if you would use a memory manager in kernel space, you could achieve the best results, since you would avoid the copies form kernel to user space and back. Do you see similarities for the 1394 stuff? Regards, Robert --- Robert Berger Embedded Software Specialist Reliable Embedded Systems Consulting Training Engineering Tel.: (+30) 697 593 3428 Fax.:(+30 210) 684 7881 email: robert.berger at reliableembeddedsystems.com URL: www.reliableembeddedsystems.com --- ......The moral is obvious. You can't trust code that you did not totally create yourself. -- Ken Thompson My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 > > andy > > >
