Re: Fast factor 2 resampling

[Tim Janik <timj gtk org>]

On Mon, 10 Apr 2006, Stefan Westerfeld wrote:

>   Hi!
>
> On Wed, Apr 05, 2006 at 02:05:37AM +0200, Tim Janik wrote:
> > On Tue, 4 Apr 2006, Stefan Westerfeld wrote:
> > > > ok, ok, first things first ;)
> > > >
> > > > as far as i see, we only have a couple use cases at hand, supposedly
> > > > comprehensive filter setups are:
> > > > -  8bit:  48dB
> > > > - 12bit:  72dB
> > > > - 16bit:  96dB
> > > > - 20bit: 120dB
> > > > - 24bit: 144dB
> > > >
> > > > if we have those 5 cases covered by coefficient sets, that'd be good
> > > > enough
> > > > to check the stuff in to CVS and have production ready up/down sampling.
> > >
> > > Yes, these sound reasonable. Although picking which filter setup to use
> > > may not be as easy as looking at the precision of the input data.
> > >
> > > For example ogg input data could be resampled with 96dB coefficients for
> > > performance reasons, or 8bit input data could be resampled with a higher
> > > order filter to get better transition steepness.
> >
> > but that'd just be another choice out of those 5, other than the obvious
> > one.
> > or am i misunderstanding you and you want to point out a missing setup?
>
> No, I was just pointing out to the fact that choosing from these 5
> should not (always) be automated for datahandles. In the plain C API,
> this means that we now have
>
> /* --- resampling datahandles with the factor 2 --- */
> GslDataHandle* bse_data_handle_new_upsample2 (GslDataHandle *src_handle, int precision_bits);
>
> instead of the old API
>
> GslDataHandle* bse_data_handle_new_upsample2 (GslDataHandle *src_handle);
>
>
> But actually there is a case that is not covered very well (and can not
> be covered with the code designed as it is right now), and thats
> resampling files with small sample rate. When it comes to that, the
> aliasing area that I've designed into the inaudible area (22050-26100 Hz
> if we're resampling 44100 Hz recordings) moves down into the audible
> area (for instance 11025-13050 Hz upsampling a 22050Hz recording with
> factor 2).

sorry, i don't understand. can you elaborate o nwhat you mean with
"aliasing area" here?

> > and when we get processor specific, we have to provide alternative
> > compilation objects and need a mechanism to clearly identify and
> > select the required instruction sets during runtime.
>
> I understand why you don't want to support _many_ object files per
> algorithm. However, it may be reasonable to support _two_ object files
> per algorithm, one compiled with -msse -ftree-vectorize and one without.
> This also needs to be done for Bse::Resampler. It may be reasonable to
> do it for common algorithms at least, like scaling a float block with a
> float value or adding two float blocks together.
>
> And we need a runtime check for checking whether SSE is available. But
> thats not a problem, because there is one in arts/flow/cpuinfo.* we can
> simply copypaste.

the runtime CPU check and build system changes to build plugins with 
and without SSE support are now in CVS HEAD.

>   Cu... Stefan

---
ciaoTJ