Andreas Monitzer wrote:
quoted text
> 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@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
 

quoted text
>
> andy
>
>
>




_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel