Re: About AUValidation
Re: About AUValidation
- Subject: Re: About AUValidation
- From: Olivier Tristan <email@hidden>
- Date: Wed, 30 Sep 2015 18:33:17 +0200
Le 30/09/2015 18:16, Christian Rober a écrit :
I too have not yet tried validating an AU on El Capitan yet. That
said I think I know what auval is complaining about. Assuming one is
using the Core Audio Utility Classes, I think your AU is still
compiling and exporting the older interface. For example, the Carbon
view dispatch/creation call is typically declared via the
AUDIOCOMPONENT_ENTRY macro (in ComponentBase.h). So, to eliminate
this warning I think you need to disable the compilation and exporting
of the Carbon Component Manager modules/behavior. This is what I did
to remove the older interface and just use the v2 AudioComponent API:
1) Use the later version of the AUDIOCOMPONENT_ENTRY macro that
doesn't create the ComponentEntryPoint::Dispatch calls. I did this by
setting CA_USE_AUDIO_PLUGIN_ONLY in the "Preprocessor Macros" section
of my Xcode build settings. You may need to wrap old behavior in your
custom AU code/implementation with this macro check to disable those
compilation units as well.
2) Remove the "_MyAudioUnitNameEntry" line from your .exp file so that
just the "_MyAudioUnitNameFactory" remains. With respect to linking,
this works in tandem with the above step.
3) Remove the rezzing build settings/phases and the respective .r
files, they are no longer needed (though I have not confirmed if their
presence is harmful).
4) Remove _some_ of the Core Audio Utility classes/.cpp files. I
don't remember which ones offhand (I know AUDispatch.cpp needs to be
removed for sure), but these will cause build errors when the above
steps are completed.
5) You may have to do a Clean then Build between some of these steps
to see any progress, what with all the linking changes.
One last warning: I know hosts have been updating to the
AudioComponent (v2) API since ML, but IIRC some still required the
older API. I assume that if a host has not yet adopted these v2
semantics, then your AU will not load, which may cause some confusion
during this upgrade.
Thanks for the detailed answer.
My main fear is indeed that it would break other AU host like Live,
Reaper or Digital Performer
Regarding the resource, we should probably only remove the one related
to kAudioUnitCarbonViewComponentType
Still this is only a warning but I suppose the latest AUVal have some
kind of "treat warning as errors"
Sounds like it's going to be a fun time :)
--
Olivier Tristan
Research & Development
www.uvi.net
_______________________________________________
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