Re: Changing the latency from within the render callback.
Re: Changing the latency from within the render callback.
- Subject: Re: Changing the latency from within the render callback.
- From: Jim Wintermyre <email@hidden>
- Date: Thu, 26 Feb 2004 12:34:37 -0800
Yep, that makes sense. I'm still in VST rehab, bear with me... :-)
Jim
At 3:32 PM -0500 2/26/04, Marc Poirier wrote:
On Thu, 26 Feb 2004, Jim Wintermyre wrote:
>On Mon, 23 Feb 2004, William Stewart wrote:
>
>> On 23/02/2004, at 1:51 PM, Philippe Wicker wrote:
>>
>> > Hi all,
>> >
>> > I've read in the documentation (html AudioUnits doc coming with the
>> > SDK) that an AU can publish a Latency property and that the AU is free
>> > to change the value of this property. I could have to use this feature
>> > and have some questions about this.
>>
>> Not typically = the property is described generally as a read only
>> property and in most cases will be read only (though of course, some
>> AU's can/will want to have this configurable).
>
>
>Just to clarify, Bill you mean that a host would not change the property,
>but it is expected that a plugin still may change it at any time, right?
>Because Philippe was talking about the plugin itself changing it, and I
>think that then you were replying about hosts changing it. Maybe I'm
>misreading, though...
My read on that is that Bill was saying that typical AU's will not
change that property. But some (like ours) will want to set it
depending on other things (buffer size for example). However it
seems to me that it might be unreasonable to expect hosts to read
this at *any* time, i.e. every render call. If you were changing
this on render calls I would imagine that would cause mayhem (or just
not work) in hosts that are doing automatic delay compensation. I
think typically plugs would want to set this in Initialize(), and
possibly change it when the stream format or the max frames per slice
changes.
I don't agree, because thanks to the property change notification system
with AUs, the plugin doesn't have to worry about when is a convenient time
(convenient for the host) to set its property values, or do any sort of
reverse psychology or predictive guessing of host behavior (like you have
to do with VST, for example) in order to insure that the host will look at
the AU's property values at the right time. All the AU has to do is
change its property value whenever it has in fact changed, and then send a
property change notification to any listeners (which is simple, just use
AUBase::PropertyChanged).
Of course with something like latency, it won't always be feasible for a
host to adapt to the change at any point in time, but it is not for the AU
to worry about that, it is for the host to decide what to do with the
knowlege that latency has just changed. If the host is in the midst of
playing back audio through the AU, it will probably make sense for the
host to just write a memo to itself about the AU's latency change and then
adapt to the change when playback is next stopped, moved, interrupted,
etc., whenever it's convenient.
This way, the AU doesn't have to make any unreliable assumptions (will the
host look at my changed value? will the host pay attention only after
Initialize? or after Reset?) and the host doesn't have to make any
unreliable (and definitely in some cases wrong) assumptions either (like
latency only changing upon Initialize, changes to stream format, or
changes to max frames per slice).
Marc
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.