Re: auval and you
Re: auval and you
- Subject: Re: auval and you
- From: Brian Willoughby <email@hidden>
- Date: Wed, 21 Mar 2007 18:12:00 -0700
Angus,
I must disagree with you for a number of reasons.
For one, you seem to be complaining that auval is not a perfectly all-
encompassing test - that there is much which is left out. Feel free
to write a better AU validation suite, but in the mean time, I would
prefer that we take full advantage of what we have, not cripple it
for an additional number of years because it isn't finding all
possible bugs. Any bug that auval finds is a serious bug. The fact
that an API validator is limited in scope as to what it can detect is
grounds to take auval failures seriously as early as possible. Apple
is doing all that can be done, by seeding strict versions of auval as
early as possible before sending them on to the general public. The
real problem you are experiencing is twofold: first, that developers
of AudioUnits are ignoring auval for years until it eventually gets
into their users hands, and second, that CoreAudio is a bit of a
secret society. The CoreAudio API SDK has long been distributed
separately from the main Xcode SDK; CoreAudio and AudioUnits
documentation updates have been available primarily through non-
standard channels compared to other Mac documentation, and auval
seeds themselves are rather secret unless your development team has a
long-time experience with AudioUnit development and has stayed on top
of things from the beginning. This is great for developers who have
AudioUnit experience, because it increases the value of their
experience, but it is bad for plugin developers who do not focus on
AudioUnits. I see plenty of room for complaints to Apple, but
nothing they've done with auval public releases is to blame.
Another point I disagree on is your assertion that users will blame a
plugin (which fails auval) for bugs that are actually present in
other (passing) AUs or in the host itself. Any user who is trying to
assign blame had better be smart enough to disable plugins which fail
auval before making any assumptions about where bugs lie. If your AU
is failing auval, but you believe it is bug free, and further that
users are mistakenly blaming your plug for bugs in other code, then
all you need to do is tell the user to test without your plugin
enabled. Failing auval should be a blessing, since most users will
end up not using your plugin unless they learn how to disable auval
for your plugin. If they're that savvy, they should be able to
figure out how to properly assign blame for bugs, whether other plugs
pass auval or not. Either way, you can address the problem by
releasing a new AU which passes auval.
In other words, I see no merit in extending auval grace periods to
allow failing AU plugins to pass when there are known bugs which can
be found by an automated tool. As you point out, there are many bugs
that auval cannot find. What we need are more test suites which can
find these additional bugs, or extensions to auval to find additional
bugs. It serves no one if auval is disabled, because that lumps all
bugs - those which can be found via API validation and those which
can only be found by running in a host - into one set, making it
harder to isolate problems, not easier.
You have a valid point: Some auval failures are fairly benign, while
undetectable bugs can be much more serious when they finally strike.
But all we should do is add to the list of detectable bugs, not add
to the list of ignored bugs.
Brian Willoughby
Sound Consulting
On Mar 21, 2007, at 03:31, Angus F. Hewlett wrote:
Given that auval is an API validator, not a full boundschecker /
purify - style error detector, and performs virtually no validation
at all on the UI and interaction code where most such crash-bugs
live, I consider it very likely that users are living with that much
of the time anyway, auval or no :o/
Seems to me that the way this is being handled has two side-effects:-
- it effectively forces a refresh cycle on to third party developers
that these developers do not want
- it creates a concrete association in the user's mind between AU API
implementation validity, and overall code stability
The problem with this is that, the moment an AU fails validation, it
will then immediately get the blame for any crashes on the user's DAW
-- which is misleading as it's trivially easy to write an AU which
will pass validation and then crash, or fail on a technicality and
yet not contain any of the kind of bugs that tend to lead to
crashing. So if A's plug fails validation, but B's plugin (or, horror
of horrors, Logic itself) is crashing the system, A will always get
the blame.
So even if Apple isn't forcing developers to make AUs pass
validation, the users do so out of a misguided association between
implementation-validity and overall code stability. Also, many users
still don't even know about the AU Validation control panel in Logic,
and don't have much understanding of it.
I don't have a problem with this if it operates over a long (2 or 3
year) cycle, that fits in with the sort of time frame over which
platform and OS changes tend to render plug-ins unreliable or
inoperable anyways, and by that time there's usually a decent
alternative to anything that's no longer being developed. However, it
seems to me that placing this much emphasis on an automatic validator
such as auval is, at best, misleading the user base.
Best,
Angus.
_______________________________________________
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