Re: Setting the AU's sample rate
Re: Setting the AU's sample rate
- Subject: Re: Setting the AU's sample rate
- From: Marc Poirier <email@hidden>
- Date: Mon, 5 Jul 2004 11:55:06 -0400 (EDT)
Jeremy,
>
I think the big problem here is a lack of explicitness in the AudioUnit
>
specification. Perhaps Bill can shed a little more light on this but I
>
went back and read some of the AU documentation and it is extremely
>
vague on which properties require the AU to be uninitialized when
>
called. For example what about
>
"kAudioUnitProperty_MaximumFramesPerSlice"? Does the AU need to be
>
uninitialized for that? I would really like to know directly whether I
>
can query for busses while the AU is uninitialized with the use of
>
"kAudioUnitProperty_BusCount" or if I can query for streams with
>
"kAudioUnitProperty_SupportedNumChannels" or
>
"kAudioUnitProperty_StreamFormat" while the AU is uninitialized?
>
>
I am now under the impression that the answer to all of the above is
>
yes.
These issues I remember have come up on the list before, and I believe
that Bill has explained that this stuff is not explicit in the AU spec
intentionally. An AU may require being Uninitialized for StreamFormat and
MaxFrames changes, or it may not. Probably an AU does require this. The
default implementations of both of these in AUBase are that an error is
returned if the AU is Initialized. But a specific AU can override that
implementation if the AU is one that does not need to be Uninitialized for
those changes. So it's not an either/or situation.
And also, as a host, you should not have to guess what the AU needs. An
AU is supposed to return an appropriate error from any property setting if
it cannot be done, and in the case of what we're talking about, a
kAudioUnitErr_Initialized error should be returned. So, if you just want
to take the simplest approach, you can always Uninitialize before doing
any of those operations. If you want to be more adaptable, you could
attempt the operation, and if Err_Initialized is returned, then
Uninitialize and then attempt the operation and and then Initialize again.
If any of these operations fail but the AU does *not* return an error,
then the AU is buggy and the developers should be informed.
>
The big problem for me is that supposedly AUInitialize can take a lot
>
of processing time (although I do not really see this) and therefore I
>
want to minimize my calls to AUInitialize
Try with some Waves plugins. :-/ Those are really heinous examples,
though; most AUs, it's true, take a trivial amount of time to Initialize,
but some do still take more than a trivial amount of time.
>
but on the other hand before
>
the AU is initialized I am unsure of which property calls are legal and
>
I do not want to break anything that currently works correctly.
>
Therefore I want to minimize changes to a working code base. I know of
>
at least one (different) AU that will crash if uninitialized because
>
of a lingering event timer.
It's not really a matter of what's "legal" but a matter of what may not
succeed, and that is rendering state related stuff that may require
reallocation and/or reinitialization of resources, so that means
StreamFormat (including SampleRate), MaxFramesPerSlice, and BusCount for
sure, maybe some others that we haven't mentioned yet.
It should always be safe to attempt any property getting or setting
regardless of the AU's state of Initialization. You may not succeed, but
no AU should ever crash as a result. Any such AU is seriously buggy and
the developers need to be told and need to fix their software.
Marc
_______________________________________________
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.