[linux-dvb] Re: V4 API Implementation Q's

[Rob.McConnell@Zarlink.Com]

                      Johannes                                                                                                   
                      Stezenbach               To:       linux-dvb@linuxtv.org                                                   
                      <js@convergence.d        cc:                                                                               
                      e>                       Subject:  [linux-dvb] Re: V4 API Implementation Q's                               
                      Sent by:                                                                                                   
                      linux-dvb-bounce@                                                                                          
                      linuxtv.org                                                                                                
                                                                                                                                 
                                                                                                                                 
                      13-Apr-2004 07:20                                                                                          
                      PM                                                                                                         
                                                                                                                                 
                                                                                                                                 











Hi Johannes!

> On Tue, Apr 13, 2004 at 06:14:11PM +0100, Rob.McConnell@Zarlink.Com
wrote:
> >
> > > Well, I think if you write a simple zapping application you would
> > > statically allocate filters for audio, video, pcr, and allocate
> > > and set filters for PAT, PMT, EIT-p/f. Then for zapping you just
> > > set some PIDs and stop/start the filters.
> >
> > A zapping app would indeed setup the A/V/PCR pids and start providing
> > streams to the decoders.  As for SI/PSI then I don't see the difference
> > between setting a filter and it starting immediately or setting a
filter
> > and starting/stopping it later.  Yes, PSI/SI filters would have to be
> > dynamically allocated/set, but why would you want to start/stop them at
a
> > later time rather than just have them start immediately or simply
> > remove/stop them (close the fd)?

> I mean one does not have to release filters before tuning, and then
> allocate, set and start a new filter. One could just stop, tune, start
> (for PAT, SDT, EIT).

OK, this scenario would make sense, in fact I think our app guys do this
anyway.  No worries with allocation of resources (h/w filter/feed) here,
whereas if we had to close the fd down and open after we re-tuned to
another mux there could always be the potential that there are no resources
left (you never know what the app(s) could potentially do).

> There is some overhead involved with open() (lookup the device node by
> name etc.), so one could argue that separate DMX_STOP and DMX_START
> ioctls would be valuable. But currently I don't think that the
> overhead is significant, so I left START/STOP out of the API
> to simplify driver-internal state handling.

I would still rather have the START/STOP ioctls in the API to provide the
necessary functionality.  I'm sure I am not the only one out there with
this requirement (IIRC the Toshiba guys favoured this as well).  A wrapper
that simulated this functionality would have some holes.  For example, the
only way you could STOP a running filter would be to close it down in the
current V4 api.  If the app wanted to START it again, you would have to
open another fd and issue the SET ioctl with your _saved_ filter attribs in
the wrapper.  Then you run into the risk of not actually be able to obtain
the resource if other processes in the meantime "stole" them.

> > I haven't looked at MHP, so do MHP apps make the distinction between
> > allocation, setting and start/stopping of filters/feeds?

> Not really. There is a separated resource management API though,
> but applications must be aware that resources can be withdrawn
> anytime, and setting/starting an allocated filter can also fail
> for various reasons...

Is there the ability to START/STOP a running filter independently in the
MHP xxx API?

> > One of the main arguments I have for providing this distinction in the
V4
> > API is to allow compatibility for existing STB API's that have been
ported
> > to Linux.  However, I do understand that this will mean extra
complexity in
> > terms of handling the state of a filter/feed, but this would at least
> > provide the flexibility that a DVB API should have.

> Well:
> - we allow more than one section filter with the same filter data
>   on the same PID in the API (e.g. two apps getting the PAT)
> - but hw does not allow that -> the driver must use the same hw
>   filter and duplicate the data to both fds

> -> filter allocation depends on data for filter setting

> Do you see the problem?

YES - this is a tricky one.  Whereas before (in V3) we closely linked
allocation of resources (i.e. filters/feeds) with the underlying h/w (at
open time), we don't have this arrangement anymore.  I'm not sure if this
is such a good thing, as you could feasibly run into the risk of not having
enough CPU/memory bw/etc. if you have multiple fds all with different
processes reading the same data (having to copy the data in the BH/tasklet
from the h/w buffer to each kernel buffer associated with the fd/process).
Then you have the context switching time to consider with all these
processes :(

OTOH, how many STBs have simultaneous reading of the same data (e.g. PAT)
by multiple apps? (not many I would suggest).

It would be nice to have this linkage between the h/w resources and either
an ioctl or open syscall, inherently preventing this situation of multiple
processes reading the same data (from different kernel buffers).  If a
system needed to allow this simultaneous access to the data, then a
wrapper/layer could be devised in user space to present the illusion of
multiple data producers.

What do you think?

Rob




-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.