Hi!
On Tue, Apr 24, 2001 at 07:21:22PM +0200, Frank#bang Haferkorn wrote:
> My solution is different. but has the same effects at fewer cpu-costs
>
> It should be necessary to implementa new module property:
>
> The new module Functionality OVERSAMPLING has to come with:
> Module wide Oversampling (=increasing of the samplerate)
> this leads to a module wide increasing of samplerate at runtime
> needs interpolation ofall nonconstant inputs and downsampling of all outputs
> by any factor x^2
>
> A module with oversampling-factor different 1 performs a RUNTIME:
> oversampling/interpolating the increased samplerate from all non constant
> input-channels
> downsampling/bandwidth-filter and sampleratereduction for all output chanells
> performing the sample stepping increased (by the oversampling factor)
>
> TODO, if accepted.
> If the above precedere is accepted, Stefan could do a simple Oversampling
> module with copying the last samples (=hold) instead of interpolating. amd
> integration (=averaging) for downsampling. (Sorry,Idon't know thearts
> intrinsics right now.)
> I will then implement the proper over/downsampling, I mentioned similar
> software earlier to Stefan.
>
> That are the resultsto the arts projects
> New Oversampling, also useful for ather time critical feedback operations
> Move all Synth_WAVE... to the new Synth_CALC... . in sourcecode.
> Redo the Synth_WAVE as module-files with oversampling using the now called
> Synth_CALC modules.
I am not perfectly sure if I understood you right, but it seems to me that
you want that oversampling thing to be something the module doesn't need
to know about. I.e. there is a new "oversampling" attribute, and if you set
it to 2.0, every sample will be doubled before it goes into the module, and
two samples will be averaged when they leaves the module. (With the
appropriate filtering to the inputs/outputs, done transparently in the
framework, not in the module).
That kind of thing is probably quite hard to implement. For now, I won't go
too much into detail, but there are a lot of things like binary compatibility,
composition of modules to more complex structures (with virtualization and
such) and so on to deal with, that make it a challanging and time consuming
task to get it right at best, and at worst, even the best possible
implementation of that might be so slow that you don't want to use it for
performance reasons.
So, I'd say it would be a lot better to keep this module-local. I.e. the
task is just: implement an oscillator module. It can do oversampling
internally, if it wishes so. That shouldn't be too hard. You get a frequency
as input (signal), and produce a band-limited signal as output. If you
need oversampling of factor 2, you can internally compute twice as many
samples as you need, and then filter and output the downsampled results.
My idea of the the theoretical benefits of oversampling are: Normally you have
-----------------------------> frequency
| | |
ssssssssssssss
0 Fs/2 Fs
and need to fit your spectrum in there. That is, you should produce a
bandlimited wave in exactly that range. If you oversample with a factor
of two, you have
-----------------------------------------------------> frequency
| | | | |
sssssssssssssjjjjjjjjjjjjj
0 Fs/2 Fs 3Fs/2 2Fs
i.e. you can fill the spectrum between Fs/2 and Fs with junk, as it will
be cut away (or at least significantly reduced) through downsampling.
Applying this to a table based approach, oversampling with a factor two
does give you the ability for instance to precalculate tables with 128, 64,
32, 16, 8, 4, 2 harmonics (which is not too much work nor too much memory),
and then you can simply use them as the harmonics that will be mirrored are
cut away by the filter.
All in all, the oversampling can lessen the requirement to cut your spectrum
"exactly here" to "somewhere between here and here". But still you have to
somehow create the wave, and I am not sure that using the trivial algorithm
(as in (pos-0.5)*2) and downsampling the result is enough with small over-
sampling factors like two.
An oversampling oscillator somehow looks like
- produce the wave oversampled (naive? table based? something else?)
- downsample it (how to filter? iir? fir? how many coefficients? what
interpolation strategy after filtering?)
which leaves still quite some choices open.
I think there are two ways how to proceed from here. One would be to take
the theoretical basics of signal processing, model an oversampling oscillator,
and see how it performs. Another would be to implement an oversampling
oscillator and see how it performs. All in all, I'd suggest you to do the
second or both ;).
Cu... Stefan
--
-* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
