Re: Connecting AU's without an AUGraph
Re: Connecting AU's without an AUGraph
- Subject: Re: Connecting AU's without an AUGraph
- From: Luke Bellandi <email@hidden>
- Date: Thu, 19 Sep 2002 10:54:36 -0700
>
I was worrying only about this specific case, with the mixer AU, which
>
is only a version 1 component. Will the mixer ever pass in any of the
>
other flags to its input callbacks? It doesn't seem that any of them
>
would ever be appropriate.
1) Setting the inputcallback of an AudioUnit will mean the specified render
function gets called once per buffer, and expect that buffer to be
2) If you call AURenderNotify for an audio unit, it means the specified
render funtion gets called twice per buffer, once before the render and once
after the render (you will always get called for both if this is turned on:
i.e., you cannot select to only be called for pre-render, and not
post-render: it's both or neither.)
Note: you can have neither, both, or one of these functions installed for
any given audiounit)
For example, if I install both callbacks on a mixer unit (and send them to
the same function), then for each buffer that unit needs to provide a buffer
of audio, it will get called three times:
1) MyRenderFunction (pre-render notification)
2) MyRenderFunction (render notification)
3) MyRenderFunction (post-render notification)
Please note that these are *always* called in sequence, and that the pre and
post render flags are provided solely to make the function aware of what
duty it is to perform.
The pre and post render flags, and related notifications are handled
automatically by the audio unit base classes, since they are not
unit-dependent. They will work for all audio units. The
kAudioUnitRenderAction_OutputIsSilence is a flag that each unit should
implement individually (it's not mission critical, it's just meant to
increase efficiency {e.g., a low-pass filter unit, seeing that flag, can
immediately return from the AURender callback without touching the data
since it wouldn't have any effect on it, thus saving CPU time.} )
>
>
The fact that the type of callback is the same for input procs and
>
rendering procs can lead to some confusion. The comments in the header
>
files seem to focus on the rendering case, and deal with a lot of
>
issues that (I don't think) apply to input procs. I think it's more
>
likely that newbies will try to do an input proc first, and the
>
documentation will only baffle them. (I know it baffled me for a
>
while...)
An input proc and a render proc are the same thing. Do you mean that the
fact that the notification proc and the render proc have the same signature
is confusing? Try thinking of as if the function is saying
1) pre-render: "I will call you to work on the following data. Make
preparations you need to."
2) render: "I am calling you to work on the following data. Render
it."
3) post-render: "I have finished working with the following data, and here
are the results. Do any clean-up you need to." (since AudioBufferList
*ioData will have the post-process data in it)
Oh I see, when you say input proc, you mean a render function, but one that
isn't concerned with the data it gets (i.e., it's not *processing* ioData,
it's *writing into* it.
The flags shouldn't be a newbie concern, that's for sure. Newbies should
use AUGraphs and ignore the flags in the render callback, as you have in
your example code.
Like I said, my emails on the subject are meant to comment on & clarify what
the flags are used for. PlayEffect was the first sample code we've released
that set up a "graph" of audiounits without using the AUGraph APIs. That
raises the issue of updating the "graph" which must be done in a render
notification.
Best,
Luke.
>
--
>
Kurt Revis
>
email@hidden
_______________________________________________
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.