Connecting AU's without an AUGraph
Connecting AU's without an AUGraph
- Subject: Connecting AU's without an AUGraph
- From: Luke Bellandi <email@hidden>
- Date: Thu, 19 Sep 2002 10:03:01 -0700
>
5. Implement your input callback
>
>
OSStatus myMixerInputCallback(void *inRefCon,
>
AudioUnitRenderActionFlags inActionFlags, const AudioTimeStamp
>
*inTimeStamp, UInt32 inBusNumber, AudioBuffer *ioData)
>
{
>
// inRefCon and inBusNumber will be whatever you passed in to
>
setUpMixerInputCallback().
>
// inTimeStamp will be the time that the audio data will be played.
>
You may ignore it if you don't need it.
>
// Ignore inActionFlags -- the stuff it describes never got
>
implemented (I think).
>
// Write your data into the ioData buffer provided.
>
>
// YOUR CODE HERE
>
>
return noErr;
>
}
A tangent from Kurt's code example:
You can find a list of valid render flags in <AudioUnit.h/AUComponent.h>:
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Render flags
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
enum {
/* these are obsolete, were never implemented:*/
/* kAudioUnitRenderAction_Accumulate = (1 << 0), */
/* kAudioUnitRenderAction_UseProvidedBuffer = (1 << 1),*/
kAudioUnitRenderAction_PreRender = (1 << 2),
kAudioUnitRenderAction_PostRender = (1 << 3),
kAudioUnitRenderAction_OutputIsSilence = (1 << 4) /* provides hint
on return from Render(): if set the buffer contains all zeroes*/
};
typedef UInt32 AudioUnitRenderActionFlags;
You're right, Kurt, in that there were 2 flags that were never implemented,
although the 3 that are can prove very useful (I suppose the comment in the
header file looks like it refers to all flags, but it's just the top two
that have been commented out that it's referring to.)
You call AudioUnitAddRenderNotify(...), and AudioUnitRemoveRenderNotify(...)
to set up the render notifications. The interesting thing here is that the
notification callbacks call an AURenderCallback. So you can set these up to
call the same function for both your rendering and your notifications. (Note
that all these functions are for AUv2, and that there are corresponding
functions for AUv1 with different names.)
To put into practice, take a look at the function
"AURenderNotifyCallbackDispatch(...)" in PlayEffect.cpp in the PlayEffect
(imagine that) example. We've set an input callback from our converter AU
to obtain data from this function.
Notice that the function dispatches to UpdateAUChainIfNeeded() on a
pre-render notification, and does nothing on a post render notification.
For clarity, there are 2 dispatch functions in that example
(AURenderNotifyCallbackDispatch(...), and AURenderCallbackDispatch(...)),
but you could just as easily have one function that handles both the
notifications and the rendering.)
One of the most useful things pre and post render notifications provide is a
legitimate opportunity to reconfigure AudioUnit connections. If you try to
make and break connections while the AU's are rendering, you'll likely crash
your system, but if you do it in a pre-render notification you're not in
danger of doing that.
In PlayEffect, when the user selects a new effect unit, that effect unit is
created, and stored in a member variable effectively 'queuing' it. On the
next pre-render notification, if that member variable contains an audio
unit, the chain is updated to include the new unit, and the old unit is
destroyed, and the member variable reset. The following call to
AudioUnitRender(...) will use the newly connected unit. Change made, no
crash.
Of course, all of this is taken care of for you if you use AUGraph, but for
those who like to do it all by hand, this is how.
_______________________________________________
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.