Host corollary to auval?
Host corollary to auval?
- Subject: Host corollary to auval?
- From: Jim Wintermyre <email@hidden>
- Date: Tue, 2 Mar 2010 16:10:48 -0800
Regarding this:
> In our case, this all comes into play because it can be
problematic if the host stops calling the plugin without some sort
of notification that is about to do so, because we are running on
hardware and have more complications with state management vs.
normal host-based plugins. So it is useful to either be able to
tell the host "always call me" (eg. infinite tail time), or "notify
me if you're going to stop calling me" (eg. sending AUReset). But
then we're back to the original problem where not all plugins
implement AUReset properly, so the host mfg may not want to call
that... or they have to special-case it for different plugins!
Sigh. The joys of plugin/host development. :)
Well, that raises an interesting point.
First: Reset is not defined to be something that you would call
before you stop.
Some hosts do...
It is called as a prelude to when you would start again. Maybe we
should add a property along the lines of "i need to know when you
are going to stop calling me"...?
Yes, that would be useful for us in particular. I suggested AUReset
because that is the only thing in the current spec that is close to
what we need. But then that tends to dilute the meaning of AUReset,
resulting in different hosts assuming they can use it in different
ways (similar to the confusion with AU bypass which we discussed a
while back).
The problem, of course, is the chicken-and-egg issue where even if
you add it, we have to get hosts to adopt it before we can count on
it, and this sort of thing is always a hard sell if it isn't
required for host-based plugins.
This has gotten me thinking about how useful it would be to have
something similar to auval, but which tests *host* behavior. It
could catch common incorrect host behavior that may appear benign at
first, but which may be important for some plugins and not others
(for example, hardware-based vs. host-based), and which would
therefore initially appear to be a plugin problem when it's actually
a host issue. It could also be useful in cases where a property is
added to the spec but isn't adopted in a certain host. It would give
more incentive to the host developer to add support if the
"auhostval" plugin flags that as a host error vs. us just pleading
with them to add it so that we can rely on it in our plugins.
Thanks,
Jim
_______________________________________________
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