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 16:41:29 -0700
On 06/07/2004, at 12:26 PM, Jeremy Sagan wrote:
>
Bill,
>
>
Okay. Now just to make sure, when an AU is uninited and then re-inited
>
does it revert to its default stream format or any other properties
>
that has been previously set by the host?
No - Initialization is *not* a call to go and reset your state.
Initialize is meant to initialize state based on the current state of
the AU. If that state is not appropriate, then Initialization should
fail (The implementation of AUEffectBase's Initialize call is to
validate that the formats are correct - if not, it fails).
Bill
>
>
Jeremy
>
>
On Jul 6, 2004, at 3:09 PM, William Stewart wrote:
>
>
> 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.
>
>
--
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.