Re: Canonical format max amp limits?
Re: Canonical format max amp limits?
- Subject: Re: Canonical format max amp limits?
- From: Stephen Davis <email@hidden>
- Date: Thu, 15 Jul 2004 10:49:43 -0700
On Jul 15, 2004, at 8:16 AM, James Chandler Jr wrote:
* If you do any non-trivial DSP float processing, its guaranteed
that there will
be conditions making the float values occasionally go WAY LOUDER
than {-1.0,
+1.0}.
Actually, in my case, I am doing fairly trivial DSP. I get my data as
16 bit signed integer since that is what both the windows code and
the linux code expect. Using the ancient Sound Manager, I could just
pass that data right through to the sound card since at least mine
and every other one that I've encountered supports 16 bit int at the
very least. Using CoreAudio, I have to convert it to float. Of
course, CoreAudio must eventually convert this back to int to send to
the card (or whatever you call it when it's builtin, device I
suppose). This step seems unnecessary but I cannot set the input
procedure format to the one I want so I am forced to convert it
before passing it along.
The default audio unit will let you hand it whatever you want so you
can give it 16-bit ints if you like. You did mention that you are
doing some trivial DSP -- is it all integer? If so, then you don't
need to convert to float at all. Most DSP algorithms are easier to
code in float though so it's typical to convert to float to do your
processing, which is how I thought this thread started...
In that case, since you are 'guaranteed' that the disk file 16 bit PCM
samples are pre-clipped, you can just multiply the integers by
(1.0/32768.0) and call it a day (GRIN).
Perhaps in this situation, a vanilla C loop would be as fast as the
CoreAudio converters, dunno. Its been a long time since I've had to
study the asm output of Mac compilers.
On PC, it almost always seems possible to shave a few clock cycles off
a tight loop by writing in asm. With auto-register assignment on Mac
(Mac has the luxury of many more registers than PC), perhaps this
isn't the case. As long as your code is 'fast enough', those few clock
cycles shouldn't matter.
Unfortunately, the PowerPC does not have a "load int into floating
point register and convert it to float while doing so" instruction so
the instruction sequence for converting an int into a float is
non-trivial. On top of that, no compiler I have ever seen (to date)
will unroll a conversion loop such that the instructions for one
conversion are interleaved with the next one. Each conversion appears
to be "atomic" to the compiler so, while it might unroll 4 times to do
4 conversions together, each one will be sequential. Given that the
instruction sequence involves multiple memory loads/stores, not having
the instructions interleaved really really sucks, performance-wise.
There are some tricks you can pull to do the conversion entirely in the
integer unit but the compilers don't schedule that too well either.
It's still better than the generic "aFloat = (float) anInt" operation
though. The CoreAudio converters do these tricks. In short, use the
CoreAudio converters. :-)
x86 has a single instruction for int -> float so it's fairly fast as
long as the compiler unrolls properly. Some compilers are better than
others at this.
stephen
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.