AU Properties and Initialization
AU Properties and Initialization
- Subject: AU Properties and Initialization
- From: Bill Stewart <email@hidden>
- Date: Sat, 29 Mar 2003 12:31:44 -0800
From our code (and I must admit that this may have different
ramifications for a ported VST unit) - there are very few if any
properties that cannot be called in an AU in an uninitialized state...
Now I'll qualify this:)
Properties are really aimed at both retrieving and specifying state
criteria
Initialization is aimed at establishing that state
I must admit a certain lax-ness in our code with regard to that
application of those design goals - and something that has become a
bug-bear for me - you'll see some more posts about this shortly...
With regard to audio units that are either effects or music devices, I
think this criteria can be applied to any property - That is certainly
true of any of the properties that we publish for those units. In fact,
it could be argued I believe that few if any of those properties are
legal AFTER an AU is initialized.
In an ideal world it would work like this:
Open
Get/Set property -
Initialize
- at that point you are expected to be able to render
Any further change in value for properties would require
uninitialization first.
But, its never as clear a situation as that, because an AU can have
very different implementation strategies...
For eg, lets take RenderQuality on the DLS synth. That setting changes
the dB level at which the synth decides that a note is essentially
silent. By changing that threshold, the synth consumes more or less CPU
and this is obviously an easy thing to do at run-time (there's no
reallocation involved, just a change in a threshold value)
However, I could well imagine that some effects may have different
algorithms for this property (lets say that a "high" quality mode would
do its rendering internally using doubles instead of floats, do
different approximations, etc.... and thus changing this at run time
could become an extensive reallocation of resources, substantially
different code paths (ie. no altivec)), complex state management...
This then, adds additional complexity to the state management of the AU
- something we had intended to avoid by providing this explicit
semantic of initialization (ie. once initialized, an AU should know of
all its possible choices, what ones it is expected to implement - this
becomes ultimately I believe, a much less error-prone implementation)...
Also, If state management is complex, and if changing this is a complex
or time consuming operation, the potential for re-entrancy issues would
have to be dealt with if this is attempted whilst the AU is
initialized... What do I mean be that?
If an AU is not initialized, then the base classes will ENSURE that the
render method is NOT called. Thus, as an AU initializes itself, it
doesn't have to worry about locking against the eventuality that it
might be asked to render. So, no locks need be acquired in the render
operation.
For eg, the render quality property is now exposed through the generic
AU view. As the user sets this, the property is changed. In AUHosting
at least, the unit is still within the render cycle (ie. the graph is
still running), so that property will be called whilst the AU is
expected to be rendering. If this is presents an opportunity (as it
would in the more complex case described above) to be pre-empted, this
creates problems, and to protect itself against that, the AU should
really obtain a lock each render cycle.
It seems a simpler semantic to us (and this was our initial design
goal) to firmly separate the establishment of state from the process of
rendering., thus, returning an error is I believe entirely acceptable
and appropriate. This might be different for different AU's and a host
application should be prepared to deal with this.
This also takes us to those properties that we can say almost
carte-blanche should NOT be settable after an AU is initialized - These
have been discussed in the past and I'll make sure to go through that
list again and publish this... If an AU does support that property when
it is initialized, then that is a "convenience"...
We are in the process of redefining some semantics in the base class
around this issue. As we do this, it would be helpful to know what
properties you would find difficult to support in an un-initialized
state if the suggestion to only instantiate the VST object on
initialization were followed.
From our implementation of the base classes, properties like factory
presets, can be retrieved from an uninitialized state (for instance)...
For some AU (such as output units) the matter is entirely more complex,
as an output unit is required to interface to an audio device, and this
association in the past has been made at initialization time. We're
still going through this.
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.