Re: AU Properties and Initialization
Re: AU Properties and Initialization
- Subject: Re: AU Properties and Initialization
- From: Marc Poirier <email@hidden>
- Date: Sun, 30 Mar 2003 00:19:45 +0100 (CET)
Hi Bill. I see what you're saying, and I guess you're right that it's not
so bad for the host to maybe uninitialize and still fail to a set a
property, but what I had in mind I don't think really requires more
complex logic. I guess I was thinking that the Initialized error implies
"this would work if I was initialized." If the property value wouldn't
work in any context, then a more stern error like InvalidPropertyValue
would be returned. Here's some purely general pseudo code of the general
protocol/order-of-events that I have in mind:
if (thisPropertyIsNotSupported)
return kAudioUnitErr_InvalidProperty;
if (thisValue == somethingTotallyUnacceptable)
return kAudioUnitErr_InvalidProperty;
if (thisValue == somethingTooWeirdToWorkWith)
return paramErr;
if (thisValue == somethingOkay)
{
if ( IsInitialized() )
return kAudioUnitErr_Initialized;
else
mPropertyValue = thisValue;;
}
Anyway, that's what I had in mind. But I'm not totally sure, maybe if I
started looking again at the specific code in the SDK, I'd see that this
logic is not as simple as I'm thinking it is, maybe you're right...
Marc
On Sat, 29 Mar 2003, Bill Stewart wrote:
>
This is a little more complex and I don't think its a good idea.
>
>
For ex, setting a stream format...
>
>
Say you don't allow setting the format if you're initialized
>
Currently you then return - nope - can't set format and you get a
>
format err.
>
>
Now - we'd have to manage extra logic to say:
>
Is that a nope because you are initialized
>
or
>
Is that a nope because you don't like the format
>
>
Thats a pain to do for the AudioUnit itself - though I guess we could
>
add additional logic somewhere (can you do this if you are initialized?)
>
>
Seems unnecessary though...
>
>
All the host has to do is:
>
Set the property -> error
>
Uninitialize the Unit
>
Set the property -> error - oh - so now it knows its actually a bad
>
value
>
>
That doesn't seem onerous to me as typically there are for most
>
properties ways you can ascertain valid property values, so, most of
>
the time you should be uninitializing the unit anyway and you are
>
probably not in a great shape by the time you've failed the second time
>
anyway and will have some work to do to recover
>
>
Bill
>
>
On Saturday, March 29, 2003, at 01:25 PM, Marc Poirier wrote:
>
>
> Bill,
>
>
>
> Thanks, this clarification is very much appreciated! There's just one
>
> little thing that I see left hanging:
>
>
>
>> It seems a simpler semantic to us (and this was our initial design
>
>> goal) to firmly separate the establishment of state from the process
>
>> of
>
>> rendering., thus, returning an error is I believe entirely acceptable
>
>> and appropriate. This might be different for different AU's and a host
>
>> application should be prepared to deal with this.
>
>
>
> This sounds fine, but unfortunately there currently isn't a clear way
>
> to
>
> say to the host, "Hey, you can't do that because I'm already
>
> initialized.
>
> You need to unitialize me if you want to do that." There is a
>
> kAudioUnitErr_Uninitialized error, but no
>
> cannot-do-that-when-initialized
>
> counterpart. So anyway, I would propose adding an error code called
>
> something like kAudioUnitErr_Initialized, because otherwise there
>
> won't be
>
> a way to clearly tell the host that unitialization is required.
>
>
>
>
>
> 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.