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

[Johannes Stezenbach <js@convergence.de>]

On Tue, Apr 06, 2004 at 07:27:24PM +0100, Rob.McConnell@Zarlink.Com wrote:
> Michael Hunold wrote:
> > If you have a hardware that mixes all these kind of filters to one
> > device, you'll have a hard time to calculate how many filters are
> > actually available of each kind.
> 
> OK, from our discussions it sounds like it will be the responsibility of
> the code "underneath" the API to control the resources.  We just specify
> the max number of *h/w* filters of each type - right?  e.g. If you don't
> have dedicated record h/w then you should set the
> DVB_DMX_CAP_NUM_RECORDING_FILTERS to 0 - correct?

Yes and no.

IMHO recording filters are such a basic feature that they
should be emulated in software if there is no special
purpose hardware for them (see av7110). Unless you write
a driver for a simple STB which won't support recording at all.

> From what I can see, the AV7110 h/w automagically returns a handle to a new
> feed with an error returned if no more resources are available, so the h/w
> takes care of resources directly - right?  For other h/w that does not
> behave like this (stuff I'm working on), you would require a conceptual
> filter slot array where you may have 32 pid filter slots N audio decoder
> slots and M video decoder slots.  You would then have to manage the
> allocation/deallocation and setting up of filters from the set feed/filter
> ioctl - is this correct?

Yes.

> > You'll always have race conditions. If you query for the number of
> > available pidfilters and the number is 1, there can always be another
> > data-harvesting application in the background that can get this last
> > pidfilter and there is nothing you can do about it.
> 
> What about the V3 API, that allocates a filter slot (with locking) that can
> later be used by the SET ioctl?

The V3 API does not make the distinction between filter allocation
and filter setting. Only the internal "kernel demux API" does this.

However, the V3 API allows one to allocate+set a filter now, and
start the filter later. I don't know how useful this is. I left
this out in V4 because the software I know does not actually make
use of it, it always sets filters with DMX_IMMEDIATE_START.

It sounds useful to make the distinction between filter allocation
and filter setting in the API. But how would this actually improve
applications?

> > IMHO this stuff isn't critical, ie. you don't need to have atomic
> > open_and_set() function, this is simply too heavy.
> 
> Is it? We seem to do this anyway in the V3 API.

Huh?

> > Setting a pidfilter can always fail (if you specified invalid
> > parameters), so you'll have to check the return code of the SETFILTER
> > ioctls anyway. EBUSY (in case there are no filters available) is just
> > another error code you need to check.
> 
> True, so you are cutting down on the check for any error at open time.
> 
> 
> Ok, another Q is regards to how the record filter adding/deletion mechanism
> works.  I asked this Q b4 in a previous email, but didn't get a reply
> (sorry if you haven't had a chance to comment).  The Q went on the lines of
> does the add pid ioctl for the record filter actually go and try to
> allocate a pid filter if one isn't already running (effectively implement
> the DVB_DMX_SET_PID_FILTER ioctl)?
> 
> Also, for h/w that doesn't have dedicated record h/w, would the output of
> each pid filter be directed to a common ringbuffer with a single copy or
> would you have a 2 copy approach - one from the h/w buffer to a kernel
> buffer and the 2nd from the kernel buffer to the common ringbuffer?  I
> would guess the later, as you may want to setup some normal pid filters
> first and then decide to setup a record in parallel as well.
> 
> The record filter is a bit of pain in terms of nomenclature and
> implementation.  I know 2 types of h/w that operate in 2 different ways.
> One is a register that has a bit position for each pid filter slot that you
> want to record and the data is dumped in a *common* area of memory.  This
> assumes that you have already setup actual pid filters in the h/w first and
> there is a dedicated record filter "slot".  The "slot" here is really just
> the common ringbuffer in memory, as no pid filter(s) is/are actually "tied"
> to this buffer.  The other h/w I know has actual pid filters that all
> connect up to a common area of memory.  In this case, you again need to
> setup each pid filter that you want to record, but there are multiple
> record filter "slots".  So what do we now class as a "feed" - a filter or
> buffer or both the filter and buffer connected together?  Does the V4 API
> handle all these record implementations without any fuss?
> 
> Finally, what are the meaning of the newly added record methods in the
> filter bank:
> 
> try_add_recording_pid
> commit_recording_pid
> confirm_recording_data
> etc.

Hm, the internal dvb-core API is work in progress, I hope Michael
can answer these questions.

Regards,
Johannes


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