Re: Canonical format max amp limits?
Re: Canonical format max amp limits?
- Subject: Re: Canonical format max amp limits?
- From: James Chandler Jr <email@hidden>
- Date: Thu, 15 Jul 2004 11:16:54 -0400
On Wednesday, July 14, 2004, at 07:42 PM, Steve Checkoway wrote:
* Though the distortion might be small, assymetrical scaling just
"isn't the
right thing to do".
By asymmetrical do you mean the scaling depending on the negative or
positive value or using one conversion from int to float and another
from float to int?
Hi Steve
Yes. A more extreme example of asymmetrical scaling can be found in
Guitar Preamp distortion emulation algorithms (because Class A tube
amps tend to have different gain at the +/- extremes of the dynamic
range).
* 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.
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.
It may be trickier to optimize packed 24 bit PCM to float, because the
three-byte samples are not aligned for efficient access.
If your program supports PC WAVE files, you also have to do the
byte-swapping song-n-dance.
On Wednesday, July 14, 2004, at 07:35 PM, Mark Cookson wrote:
The converter routines that run for AudioUnits use AltiVec (I'm almost
certain of that).
The clipping routines that kernel drivers use, like AppleOnboardAudio,
AppleUSBAudio, and AppleFWAudio use to take the floating point samples
from the application and send to the hardware DO NOT use AltiVec,
though they do use highly optimized floating point and integer
routines.
Third party device driver developers probably use the same routines
that AppleOnboardAudio uses (because that's what is also in the sample
code PhantomAudioDriver).
Thanks for the great info, Mark!
Why would you want to convert from floating point to integer within an
application at super fast speed? Don't you want to keep everything
floating point? If you do need to convert for file storage, who cares
about the float->int conversion? The hard disk is the limiting factor
there. I suppose that you could use AudioUnits and then the hardware
in Hog mode and send it integer values, but usually you do that
because you're generating integer samples to begin with.
Good points.
(Dumb discussion in case it might be useful to somebody)
From an application's perspective, it is valuable to get audio into
float format as soon as possible, and keep it in float format as long
as possible.
Its great if CoreAudio applications can send floats to the audio
output. Similarly fantastic if one can receive float streams from audio
inputs. If one were to use float audio as the program's native disk
format, perhaps one would never have to do conversion, except for disk
audio import or export!
There are so many audio file formats, if one can use CoreAudio
converters to handle disk i/o, it would beat heck out of writing a
bunch of specialized converters. If the CoreAudio converters are even
half-way optimized, 'even more gooder'.
Here is an interesting 'peripheral' float->int issue in optimization--
In processes like modulated delay lines, it can be convenient to
maintain float buffer head-tail pointers. The float pointers must be
converted to integer on each sample, to access the samples. This
conversion can be a bottleneck, since it is performed so frequently.
JCJR
_______________________________________________
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.