AU Manifesto (was Re: AUView opening before initialzation BIG HASSLE!)
AU Manifesto (was Re: AUView opening before initialzation BIG HASSLE!)
- Subject: AU Manifesto (was Re: AUView opening before initialzation BIG HASSLE!)
- From: Bill Stewart <email@hidden>
- Date: Mon, 8 Sep 2003 12:47:36 -0700
(sorry - had to resend this and snip Urs original post, as I'm getting
a too big notification)
OK - well I'm going to describe what our implementation does, why it
does this, and where I think the main problems are with current
implementations. I'll try to make this brief and concise.
The AUBase implementation was designed to hold ALL of the state of an
AU. Much of the functionality of the properties and parameters are
handled by these set of classes.
NONE of this state is dependent on whether the AU is initialized or not.
So, what is the difference?
The intention through this implementation was to separate the state
machine of the AU with its render state. When initialized, the
intention was to at that time, allocate resources (like delay lines,
etc) that are needed for Rendering. It was *NOT* the intention that an
AU's parameter state (or any of its state expressed by properties)
would also be allocated at that time - at least in the majority of AU's.
Through this separation, the base classes are able to maintain
parameter values (and to dispatch rendering based on both intra-buffer
parameter changes, ramped parameter changes, etc), and to both save and
restore an AU's state. The intention here is that the base classes
would provide all this work with *NO* need for developers to change
this. We had expected that developers could use *all* of this code, and
just have to deal with the really hard part of writing their DSP.
In recognition that there is already substantial bodies of code out
there that do not honour this separation (some of these for valid
reasons of course) we've allowed an AU to return
kAudioUnitErr_Uninitialized from parameter calls. I have some regrets
about this (as I see this becoming a standard, not exceptional
practise). This basically leads to a blurred distinction between:
(1) General AU state - an Open AU
(2) Render AU state - an Initialized AU
We had originally thought of this 'exception' as being only applied in
some special cases - for instance, the Matrix Mixer uses elementID to
discriminate Global, Input, Output, Cross-Point volumes and uses the AU
API with a slightly different semantic than an effect or a music device
AU.
Our reference implementation supports this separation.
To my mind, a host that does this:
Open an AU
set a couple of standard properties (like formats)
Initializes an AU
sets the remaining properties
Is in many ways basing its usage of an AU as if it were a similar
entity to other plug in formats that do not provide for this
distinction. By this I mean, that an AU should (at least in the spirit
of its design) be totally configurable by a user without requiring
either initialization or rendering. Thus:
Open an AU
Configure it... (including UI)
You have to render? I'll Initialize the AU...
If an implementation is not using, or circumventing the reference
implementation we publish in the SDK, then we would hope that that
implementation is honouring the spirit of the AU design. In many cases
this is not the case unfortunately, and we are doing our best to work
through these discrepancies.
I think we fully acknowledge that we haven't explained ourselves as
completely as we could (and I think in some part we've been blinded by
our own familiarity and assumptions that this would be used by others).
To address this we've developed the validation tool to make explicit
the expectations that are implicit in our implementation as well as to
acknowledge that our implementation is not the only one, and that
others deal with constraints that imply that our assumptions cannot be
used as a basis for theirs.
To try to make this more explicit we will include some examples in the
SDK of how we implement our AUs - by subclassing the kernels for
effects, by having these render kernels call back into the AU to get
parameter values at render time, etc... in short, to keep the different
state where we think it belongs.
We also I think need to provide a better base class for music devices,
though given the present situation with effect units, I'm not sure if
we did this, that many developers would use it.
I think to try to improve the validation tool, I'll add a -strict
option that will *not* accept effects or music device AUs returning a
requirement to be initialized- and maybe after a period of time, we can
actually make this a requirement for a compliant AU.
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.