Re: Setting the AU's sample rate
Re: Setting the AU's sample rate
- Subject: Re: Setting the AU's sample rate
- From: William Stewart <email@hidden>
- Date: Tue, 6 Jul 2004 12:09:08 -0700
I agree with everything Marc has said...
For my mind the common practise that a host should adopt for AU's is:
if (Bus (Element) Count/MaxFrames/Format change)
Uninitialize
apply change
Initialize
And to reinforce what Marc said - if the AU isn't behaving well after
having done this, then its a bad AU and the developer of the AU should
be told and asked to fix it.
The validation tool goes through these steps, but obviously can't
validate that the audio produced after these is good...
Bill
On 05/07/2004, at 8:55 AM, Marc Poirier wrote:
>
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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.