[openbeos] Re: Resampling algorithms for audio mixer

2007/11/27, cyanh256@xxxxxxxxxxxx <cyanh256@xxxxxxxxxxxx>:
> Stefano,
>
> I'm a bit busy with the Haiku MIDI interface project at the
> moment, but once that's wrapped up (end of the week
> maybe?), I'll certainly do some listening tests on the
> resampling algorithms.

Ok.

[...]
> My thoughts so far --
>
> I skimmed through the code quickly, but I didn't see any
> reference to lowpass filtering -- this is usually required prior
> to downsampling the audio (to avoid the frequencies above
> the new nyquist wrapping around), although is unnecessary
> when upsampling.

In fact there isn't. The code now  is just a very basic math-level
intepolator, so I don't think it can be used as it is inside the audio
mixer (IMHO it would need no big modifiiccattions however).
Regarding lowpass filtering for downsampling, it shouldn't be a
problem to add, but it can also be applied before the interpolator
itself, so that an advanced user might disable it and/or the same code
can be reused for other purposes (can''t think of any actually, since
for example a math engine would need much more precision than regular
floats).

> Upon further thought, I don't think it's entirely necessary for
> this specific application -- only if the code were to be used
> in some wider context. The reason being, the media kit
> mixer spends most of its time upsampling -- all soundcards
> made in the last 15 years run at 44.1kHz to 192kHz, and most
> recordings are made at 44.1kHz or lower
> The only common case where downsampling would be
> required is when playing a DVD (48kHz) on a 44.1kHz
> soundcard, and in that case, the content between 22kHz
> and 24kHz would wrap around to 20kHz to 22kHz. This is
> ultrasonic content (and there isn't much there to begin with)
> so it probably isn't necessary to filter it out.

Ok.

> 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.

*hehe*

This is one thing I checked quite well (I hope). It should work on
little buffers without problems (if you take a closer look the
interpolation "continues" also where it is "normally" impossible by
assuming unchanged slopes/coefficients).
A problem, instead, is heavy upsampling (I'd say more than 4x), since
the last values of each output buffer are guessed as described above,
but I think that this problem is common to all interpolators around
(maybe not if you use FFT - one could also consider some "shadow zero
values" at the beginning and end of the input buffer, or use the input
buffer as it was circular).

> Regarding the denormal optimizations, this is usually a serious
> issue in multimedia -- even on my old AMD machine, I've seen
> slowdowns in the order of 200x or more when the numbers
> become small enough.

Yes, I know.

> Rather than put workarounds for the denormal problem in
> the resampling algorithm (thus slowing it down), I propose
> completely disabling denormals on the CPU across the entire
> OS as standard.

This is up to Haiku devs :-)

Best regards,

Stefano

Other related posts: