Re: Fast factor 2 resampling
- From: Tim Janik <timj gtk org>
- To: Stefan Westerfeld <stefan space twc de>
- Cc: beast gnome org
- Subject: Re: Fast factor 2 resampling
- Date: Tue, 18 Apr 2006 17:39:30 +0200 (CEST)
On Mon, 10 Apr 2006, Stefan Westerfeld wrote:
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
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
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
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
the runtime CPU check and build system changes to build plugins with
and without SSE support are now in CVS HEAD.
] [Thread Prev