Re: Datahandle State API changes

[Tim Janik <timj imendio com>]

On Mon, 27 Nov 2006, Stefan Westerfeld wrote:

> On Sat, Nov 25, 2006 at 05:48:51PM +0100, Tim Janik wrote:
> > On Mon, 6 Nov 2006, Stefan Westerfeld wrote:

> > > + * state which means that the value of one input sample affects not only
> > > one
> > > + * output sample, but some samples before and some samples after the
> >
> > s/and/or/ (since that depends on the filter type)
>
> Writing "or" could mean that either some samples before or some samples
> after the corresponding sample are affected, but not both.

nope, in natural language, "or" can mean exclusive or and non-exclusive or,
but i'm still fine with your new wording.

> > > + * "corresponding" output sample.
> > > + *
> > > + * Often the state is symmetric, so that the number of output samples
> > > affected
> > > + * before and after the "corresponding" output sample is the same. Then
> > > the
> > > + * function returns this number. If the state is asymmetric, this function
> > > + * shall return the maximum of the two numbers.
> > > + *
> > > + * If multiple data handles are cascaded (for instance when resampling a
> >
> > hm, "cascaded"? i'd rather say "nested" (or "chained") here.
>
> Ok: I'll use cascaded.

i don't think "cascaded" is accurate here. cascaded handles could mean
using handles in parallel (e.g. you could line up 6 handles in a specifically
ordered cascade to produce a 5.1 dolby handle ;)
only "nested" and to some extend "chained" carry across the sequential
ordering of the handles.

> > > Index: bse/bsedatahandle-resample.cc
> > > ===================================================================
> > > --- bse/bsedatahandle-resample.cc	(revision 4068)
> > > +++ bse/bsedatahandle-resample.cc	(working copy)
> > > @@ -136,7 +136,7 @@ protected:
> > >  }
> > >
> > >  /* implemented by upsampling and downsampling datahandle */
> > > -  virtual BseResampler2Mode mode	() = 0;
> > > +  virtual BseResampler2Mode mode	() const = 0;
> > >  virtual int64		    read_frame  (int64 frame) = 0;
> > >
> > > public:
> > > @@ -222,18 +222,38 @@ public:
> > >
> > >    return n_values;
> > >  }
> > > +  GslDataHandle*
> > > +  get_source() const
> > > +  {
> > > +    return gsl_data_handle_get_source (m_src_handle);
> > > +  }
> > > +  int64
> > > +  get_state_length() const
> > > +  {
> > > +    int64 source_state_length = gsl_data_handle_get_state_length
> > > (m_src_handle);
> > > +    if (source_state_length < 0)
> > > +      return source_state_length;
> >
> > huh? why should a datahandle every return a negative state?
>
> Well, I thought of that line as a similar error propagation as I do in
> read - that is, if the source handle does something strange, I pass it
> on.
>
> What if the source handle had infinite state (like an IIR filter)?

then we return that, the best approximation would be G_MAXINT64.

> But I
> can also simplify it to a g_return_if_fail(), for as long as there are
> no datahandles with non-finite state or othor "errors".

as i said previously, there's no "error" handling defined for this function.

> Here is the new patch:

just pasting the changed portions would have been enough, it's not like the
patch needed a major overhaul here. provided the above stuff is fixed it 
should be ready to go in i think.

>   Cu... Stefan

---
ciaoTJ