[openbeos] Re: Resampling algorithms for audio mixer
- From: cyanh256@xxxxxxxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 27 Nov 2007 17:48:29 GMT
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.
I'm not really familiar with the internals of the media kit
enough to actually integrate anything into the mixer
though (although one day I'd like to make some significant
changes to the media kit mixer -- it needs calibration marks
for a start!).
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.
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.
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.
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.
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.
Apparently this is possible somehow, because Mac OS X
does the same thing. This can make multimedia development
a lot easier, and makes for faster code too. I don't think any
applications rely on numbers that small, because otherwise
they'd break when ported to OS X.
Does anyone have any thoughts on this?
- Cyan
Other related posts:
