Re: AudioUnit basics
Re: AudioUnit basics
- Subject: Re: AudioUnit basics
- From: Kurt Revis <email@hidden>
- Date: Sun, 16 Sep 2001 07:26:58 -0700
Well, here's my understanding of the situation. Someone please correct
me if I'm wrong about any of this.
So I'm planning out my next stage in my series of increasingly
complex-yet-amateurish CoreAudio apps and am contemplating using the
AudioUnit/AudioOutputUnit structures as mentioned in the CoreAudio docs.
The main problem - I don't have a clue how to go about doing it. The
CoreAudio docs aren't particularly helpful
The docs are pretty useless, yes.
The thing you need to know is that AudioUnits are Components, which are
handled by the Component Manager (which is part of Carbon)--which is
somewhat obscure, since most people never need to mess with it. You
might want to read the first few sections of the Component Manager docs
to get an idea of what it's for.
http://developer.apple.com/techpubs/macosx/Carbon/runtime/ComponentManager/
Component_Manager/index.html
typedef CALLBACK_API_C( ComponentResult , AudioUnitGetParameterProc
)(void
*inComponentStorage, AudioUnitParameterID inID, AudioUnitScope inScope,
AudioUnitElement inElement, Float32 *outValue);
This is declaring the type of a function, which an AudioUnit would
implement. The function would be something like
ComponentResult AudioUnitGetParameterProc(void
*inComponentStorage, AudioUnitParameterID inID, AudioUnitScope inScope,
AudioUnitElement inElement, Float32 *outValue)
I think CALLBACK_API_C is a macro provided by the Component Manager (or
some other Carbon thing?). See the headers in
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/
Headers/Components.h, if you like.
EXTERN_API( ComponentResult )
AudioUnitRemovePropertyListener(
AudioUnit ci,
AudioUnitPropertyID inID,
AudioUnitPropertyListenerProc inProc)
FIVEWORDINLINE(0x2F3C, 0x0008, 0x000B, 0x7000, 0xA82A);
For the end user, this boils down to a function declaration:
ComponentResult AudioUnitRemovePropertyListener(
AudioUnit ci,
AudioUnitPropertyID inID,
AudioUnitPropertyListenerProc inProc)
You can call this just like any other function.
It looks like there's no AudioUnit interface or protocol,
It's not Objective-C, no.
any good
sample code of AudioUnits out there?
I haven't seen any good sample code for writing a new AudioUnit yet. Nor
have I done it yet, either!
If I were you, I would start with hacking around with actually using the
AudioUnits in the system, just to get familiar with the
AudioUnit/AudioGraph API -- I've been fooling with it this week, and it
was a reasonable thing to take on.
(What I did was: take a look at the project in
/Developer/Examples/Java/CoreAudio/SDK/MIDIGraph, but make it work in
ObjC. The Java version doesn't work at all, but it does give you an idea
of what calls you need to make and when.)
Speaking of which, hey CoreAudio guys, why did you even ship this Java
sample code when it didn't work? I had to fiddle with the project to
make the Java app build correctly--as it is, it won't even find its
principal class when starting up. And even after that, I had no luck at
all running it, which I assume is due to the Java bugs you've told us
about already.
Are AudioUnitPropertyID's and AudioUnitParameterID's
programmer-defined as opposed to Apple/API defined?
They are defined by whoever writes the AudioUnit you're using. All AUs
have to handle some properties (and parameters? not sure) which are
defined by Apple, in AudioUnitProperties.h.
What are their types
made of - are they ints, floats, 4 packed chars?
The property/parameter IDs are just ints. There are some notes as to
what types of data go with what properties, in AudioUnitProperties.h.
Certainly not enough docs, but enough to get started playing around.
Do I have any reason
to care about what's in AudioUnit.k.h?
You know, I have no idea why those .k files are there. I think they are
used internally when building the components, but I don't think they
needed to be given to developers. I've been ignoring them.
Last, it looks like AudioUnits require the use of C methods (as
opposed to allowing Obj-C methods) for everything specified - am I
wrong?
There is no Objective-C API to CoreAudio, no. It would not be
particularly hard to write a wrapper around the API, though. (There is a
Java API, which gives you an idea of what an Obj-C API would look like.)
But you can call any plain old C method from Objective-C, without doing
anything special. So this isn't a huge problem, just an annoying one.
I am hoping that CoreAudio (especially the documentation) will be a lot
more complete in 10.1. Crossing my fingers...
--
Kurt Revis
email@hidden