Re: from (Aiff.h || soundmanager) to OS X
Re: from (Aiff.h || soundmanager) to OS X
- Subject: Re: from (Aiff.h || soundmanager) to OS X
- From: Ian Ollmann <email@hidden>
- Date: Tue, 4 Sep 2001 14:41:50 -0700
>
Until I write sample rate convertors (e.g. 48khz to 44.1khz)
>
I'm just using the long double to divide the audiodevice's rate and use
>
that as a multiplier for how long to hold samples per place in the
>
audioBuffer.mData.
You dont have to write a rate converter for every pair of sample rates
(e.g. 48 kHz to 44.1 kHz). All you have to do is write one converter that
slows down or speeds up a sample stream by a ratio passed in by the caller
(e.g. 44.1/48). Actually, you need to write one for stereo, and one for
mono, but you get the idea. It will sound a lot better if you use linear
interpolation to get a better estimate of the correct sample value when
the slowdown/speedup calls for samples that occur between two parent
samples.
>
As in my other post (converting aiff sound data to Audiobuffer.mData)
>
I'm mainly just stuck on how to segment the sound data into the proper
>
byte-sized pieces according to the bit-depth field and then convert
>
that to a (properly scaled?) float (which seems to be the format of
>
choice for the AudioBuffer).
The easiest thing to do is to use the Sound Converter or AudioConverter
API's to do this for you. I recently posted some code on how to do the
SInt16->float(-1.0...1.0) conversion quickly if you really want to see
how these things are done. Since then, I've gotten a few improvements sent
to me (a better abs() and a load/mask optimization) that improve the speed
of the code a bit more. A method modelled after the PPC compiler writer's
guide still works the fastest for bulk data.
Due to the way memory works, you are usually better off if you can do rate
conversion, volume adjustment and format conversion in a single function.
(Load, resample rate, convert format, adjust volume, store.) However many
audio architectures pursue a more modular design with separate functions
for each because there are a lot of different sample formats and it gets
impractical to write so many functions. Also, simple functions are are a
lot easier to debug. I suppose that in some cases some of these tasks
might be handled in hardware.
Ian
---------------------------------------------------
Ian Ollmann, Ph.D. email@hidden
---------------------------------------------------