[openbeos] Re: Resampling algorithms for audio mixer

2007/11/28, François Revol <revol@xxxxxxx>:
> > 2007/11/27, cyanh256@xxxxxxxxxxxx <cyanh256@xxxxxxxxxxxx>:
> > > The other thing I noticed while skimming through was that
> > > there doesn't seem to be any kind of encoder state
> > > preservation between calls to the resampling function.
> > > When working with small buffers (typical of soundcard
> > > buffers in BeOS -- I'm using a buffer size of 64 frames),
> > > there's the danger of inaccuracies appearing at the initial
> > > (or last) samples, which could become audible as a tone
> > > at these buffer sizes. Providing some way for the function
> > > to know what samples occured at the end of the previous
> > > buffer (such as passing a state struct into the resampling
> > > function) generally clears it up.
> >
> > What about "interpolating remaining one sample behind the input
> > buffer" (so that you cannot have to interpolate values beyond  the
> > innput buffer) and passing the last 3 or 4 samples of the previous
> > input buffer through a struct, as you suggested, so that the values
> > you now have to inteprolate before the input buffer are well defined?
> >
>
> Unless it's used elsewhere than the system mixer that shouldn't be a
> problem, just maintain a list of opaque cookies keyed on the
> media_destination (the input index).

It shouldn't be a problem wherever it is used, since passing such
opaque type would just mean that *you want* to take advantage of
previous input.

> Or put the state into a resampler object, and override a base class.
> You'll need one object per input anyway as input rates will differ on
> each input and so must be stored somewhere.

Maybe that should be done outside of the mixer and use it inside it...
maybe you could also give a look at libsamplerate (which is GPL or
LGPL licensed, I don't remember). IIRC it misses the algorithms I
proposed here (maybe I could contribute to them if you want to use
it).

> There is no reason for an input to receive non-consecutive buffers,
> since it's connected to a single output, so it should be enough to
> store the state there.

You could use non-consecutive buffers taking advantage of such states
if you manage to pass the right data... and it's even possible to "hot
switch" the resampling algorithm while running. So I really don't
think there is any problem, actually.

Anyway, tell me what you want me to do: maybe build up a little
library (in C possibly - I'm not very familiar with C++)? Adjust the
algorithms? The only thing I cannot do is integrating it into Haiku
since I have problems with it.

Stefano

Other related posts: