Re: Application Behaviour when AU returns kAudioUnitErr_Unauthorized
Re: Application Behaviour when AU returns kAudioUnitErr_Unauthorized
- Subject: Re: Application Behaviour when AU returns kAudioUnitErr_Unauthorized
- From: "B.J. Buchalter" <email@hidden>
- Date: Fri, 06 Jan 2006 00:31:17 -0500
- Thread-topic: Application Behaviour when AU returns kAudioUnitErr_Unauthorized
on 1/5/06 7:22 PM, Andrew Kimpton at email@hidden wrote:
> If our AU is not authorized we return kAudioUnitErr_Unauthorized from
> the Unit Initialize() method.
>
> However some hosts seem to either 'ignore' this error or at the least
> continue on and try to open the Unit's view component even if the
> above error is returned.
>
> It seems to me that if the process component returns any sort of
> error from Initialize then 'all bets are off' and the unit is not
> usable, and that includes not attempting to open it's UI (after all
> what's the UI going to control ? There's no process component). Or am
> I missing something here ?
Actually, it is worse than this. If the AU returns any error during the
component load or initialization, some substantial number of hosts don't do
the right thing. Unfortunately, a large number of hosts will crash when the
component returns an error during load or initialization.
What we were expecting was that if we returned an error during the component
open phase, hosts would simply ignore the plug-in (and not even display it
as an instantiable AU), but instead most hosts show a "zombie" AU, that
generally crashes the host when instantiated. Similar things happen when if
the kAudioUnitErr_Unauthorized is returned during Initialize(); perhaps not
quite as bad, but not a good user experience.
We have determined that it is not reliable to return an error, given the
current behavior of hosts. Instead, act as if everything is OK as far as the
API is concerned, but don't actually process the audio (and of course,
inform the user).
Host writers -- it would be very cool if you folks actually handled reported
errors during the Component Open and Initialization phases.
I would recommend the following semantics:
Error during Open
-- the AU is not valid; don't treat it as an AU at all.
-- errors at this stage are due to the AU not even being able to create
the base AU component. Nothing useful can be done.
Error during Initialize
-- the AU is valid, but not usable. Put it in the list greyed out, and
report to the user based upon the reported error.
But, that being said, given that there are a large variety of hosts that
don't handle this correctly, I don't think any AU writer can currently rely
on being able to report errors during initialization or component open
phase.
Best regards,
B.J. Buchalter
Metric Halo
5 Donovan Drive
Hopewell Junction, NY 12533 USA
tel +1 845 223-6112
fax +1 603 250-2451
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden