Re: Initialize, Cleanup, State
Re: Initialize, Cleanup, State
- Subject: Re: Initialize, Cleanup, State
- From: William Stewart <email@hidden>
- Date: Mon, 12 Dec 2005 11:12:23 -0800
On 11/12/2005, at 10:32 PM, Art Gillespie wrote:
I need to check my mental model of the Initialization/Cleanup/State
Persistence stuff and ask some questions.
Here's how I currently understand it:
An Audio Unit is expected to maintain its user-facing state
(parameters, settings, etc.) across paired Cleanup/Initialize calls.
Is that correct?
Yes - imagine for instance, that the sample rate of a session
changes; this is a format change so all of the AUs in that session
will be un-initialized, set to the new sample rate, re-initialized.
You can test this out in AU Lab by just changing the sample rate of
the device you are using.
If it *is* correct, where would this leave loaded samples? Should
a plug-in unload them on Cleanup() and reload during Initialize()?
The documentation for Cleanup ("This function may be used to return
an Audio Unit to its uninitialized state, causing it to release
resources without closing the component") suggests that it should,
but that seems like a lot of heavy lifting for a simple sample rate
change.
That's one thing that can configure such a change. A couple of other
things might be:
(1) Change to the I/O Size
- you can also do this in AULab by just changing the size of the I/
Os - this will go through a similar pattern to set a new max frames
(2) There was a desire by some host apps to be able to uninitialize
AUs that are not currently in use (lets say their tracks have been
muted for instance). The reason they would want to do this is to save
unused memory, etc... Because AUs at that time did not properly
implement the Init state (basically the problem was that if you had a
view open on many AUs and you uninitialized the AU, then just
touching something in the view would lead to either a crash or memory
corruption). That plan was abandoned :-(
- we did add a menu item in AU Lab to Uninitialize the session for
this reason and we've hoped that developers are testing against this
(there have been several emails on this list about this topic).
(3) When an AU is closed its cleanup call is made (either by the
implementation or by the host explicitly calling AudioUnitUninitized)
Basically, you don't know the reason for the change or when (or even
if) the Initialize call will follow, so you can't assume it.
Also, I found it difficult to nail this whole subject down: the
aforementioned documentation didn't turn up any mention of
maintaining state across these calls, and neither did grepping the
CoreAudio SDK headers and source. Is there a Single Point Of Truth
somewhere that I'm missing or is this aspect of the Audio Unit
specification more of an Oral Tradition thing?
Its been a part of auval since its inception, and discussed on the
list many times.
Bill
Thanks,
Art
--
Art Gillespie
CEO
Glaresoft, Inc.
e. email@hidden
a. bitshift189
p. 520.245.7839
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
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
________________________________________________________________________
__
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden