Re: Setting the AU's sample rate
Re: Setting the AU's sample rate
- Subject: Re: Setting the AU's sample rate
- From: Jeremy Sagan <email@hidden>
- Date: Tue, 6 Jul 2004 15:26:14 -0400
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?
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.