Subject: [linux-audio-dev] Re: Bandlimited interpolation suitable for realtime audio
From: Benno Senoner (sbenno_AT_em.gardena.net)
Date: ke syys 01 1999 - 06:16:35 EDT
Hello Julius, thank you for your very useful responses !
>
> Hi Benno,
>
> Your analysis of bandlimited interpolation requirements is correct, and your
> appraisal of the general trade-offs appears fairly complete.
> We normally use bandlimited interpolation for offline sampling-rate
> conversion. For real-time work, we generally use either linear-interpolation
> + oversampled wavetables, or highly optimized conversion filters for certain
> fixed sampling-rate ratios.
We want to create a free, flexible high- perf. audio engine for Linux
see: http://www.angelfire.com/or/audiality/audiality.html
and it will provide a sample-playback engine with flexible modulation
possibilities, that means we must allow dynamic pitch change during
playback, therefore we can't use conversion filters.
>
> Emu (now part of Creative Labs) samplers have been doing bandlimited
> interpolation in VLSI for many years. Other samplers lacking special
> interpolation hardware tend to use simple linear interpolation,
> and they might also cross-fade from one table to another as the conversion
> ratio goes beyond a certain point. (Have a separate table for each octave,
> say, and oversample by a factor of 2.)
Just for curiousity: Is the transposition range of the Emu samplers limited (downwards),
since bandlimited interpolation CPU usage is determined by the resampling
rate ? ( -2, -3 octaves ?)
>
> For a Linux real-time environment on the PC,
> I think I would recommend the use of oversampled wavetables and linear
> interpolation. It can be surprising how good simple linear interpolation
> sounds with an oversampling factor of two or more.
> Your proposal for polynomial interpolation, oversampling by 2,
> and limiting to one octave is a higher quality version of what
> I'm suggesting.
Yes, but my concern is that if we oversample by 2,
since we allow to sample-playback modules to be routed through various
modules like FX-processors , filters etc, we have to run the entire engine
at twice the samplefrequency, and this means twice the CPU load,
Is there no other way to allow flexible voicerouting AND avoiding
to run the entire engine at twice the samplefrequency ?
I think the overhead between linear and higher order polinomial
interpolation is not very big compared to using bandlimited interpolation,
(5-6 mulitiplications per sample is not very much)
therefore I'm thinking about which polinomial-order to use to have
the best tradeoff between quality and CPU usage.
Linear interpolation may work well for playing the sample data at higher
pitches, but for extreme downwards transpositions (-2 octaves) , the
signal has too many edges IMHO.
Has the Spline approach ( 4th order) some signal quality advantages
(worst/best in terms of dB) over let's say quatratic/cubic interpolation ?
(assuming a max transposition range of -2 octaves / +1 octave).
>
> As processors get more powerful, it might make sense to introduce an option
> for turning on bandlimited interpolation at various compute levels
> for real-time use. What I've always wanted was to be able to say to the
> audio service "keep audio processing less than or equal to x% of total
> bandwidth", and have the system allocate compute-power up to that limit.
> Thus, during a solo passage, some heavy-duty interpolation might be running,
> while during multivoiced "pads", the system might only be able to afford
> linear interpolation for that many voices under the current bandwidth budget.
Yes, that would be very nice, the goal of Audiality is to give the user
the choice of various interpolation methods, by using pluggable resampling
modules, therefore implementing your dynamic interpolation-method algorithm,
would not be too difficult, since if the user sets a CPU upper limit of
70% the engine could measure CPU usage, and when the CPU is idle or lightly
loaded, the engine could switch interpolation algorithm on the fly (by using
function pointers) , for the loudest voices. (or these with the most sensible
sample material,but this would be hard/impossible to determine automatically).
> A similar "budget" system could be applied to memory usage.
> I've worked with some game designers, for example, who have requested
> that audio consume no more than 10% of the processor bandwidth, since they
> want the rest for graphics. A budget-based approach is just what they
> wanted. Of course, the musicians among us might want to devote almost 100%
> of the processor to audio, and they should be able to shoot for that and
> get the best results they can.
Yes, leave the choice to the user if he wants low CPU consumption or
high audio quality.
regards,
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST