Re: Host corollary to auval?
Re: Host corollary to auval?
- Subject: Re: Host corollary to auval?
- From: William Stewart <email@hidden>
- Date: Tue, 2 Mar 2010 17:05:08 -0800
AULab was provided as a reference host - the idea here was that if your AU works correctly in this host, any other hosts that show a discrepancy are technically out of spec and we have a starting point for a conversation
If we have don't provide features in AULab that you feel are needed, we can consider them.
Bill
On Mar 2, 2010, at 4:10 PM, Jim Wintermyre wrote:
> 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