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: William Stewart <email@hidden>
- Date: Mon, 1 Mar 2004 16:21:37 -0800
I tend to agree with Marc here... It seems to me a somewhat week
assumption to be make (and I know that this is not true for some hosts)
that the render frames you are asked to produce can vary (I'm not
condoning that necessarily, but it is a reality). For instance, some
hosts will achieve ramping by changing a parameter's value over time,
then calling the AU for smaller slices of audio over that time... For
some AU's that have this internal buffering, they've actually forgone
to publish parameter info because they can't deal with this kind of
manipulation. (Now, with an AU this is NOT needed of course, as
parameter values can be scheduled intra-buffer).
But, in the case we're describing, I don't know if I've got a great
solution/suggestion - but I wanted to pose the question - have you
thought of having your latency be a property that is somewhat
independent of the number of frames you're asked to render for (and
potentially a settable property)... Its probably some amount of work
within the AU to make this successful, but it might actually be a
reasonable feature (that could have default values expressed in terms
of some relationship to the maxFrames value). Just a thought
Bill
On 26/02/2004, at 10:08 PM, Marc Poirier wrote:
>
After reading this, I wonder, why is your latency dependent on each
>
render
>
slice size?
>
>
Marc
>
>
>
>
On Thu, 26 Feb 2004, Philippe Wicker wrote:
>
>
> I myself cannot figure how a host could manage delay compensation if
>
> AUs latency is changed at *each* render calls or even only very often.
>
> Notice however that "changing this latency at *any* time" - including
>
> while in the render callback - does not mean changing it at *each*
>
> render calls. In my particular case, the latency will be exactly the
>
> size of one render buffer, ie the size which is passed in the render
>
> callback parameter inNumberFrames. As far as I have understood, this
>
> value is under the control of the host. Running with Logic, which is
>
> the host I use for my testings, this size is chosen in the "Audio
>
> Drivers" panel. I cannot query this information from the host before
>
> Initialize method is running (no api I know about for this). I don't
>
> have either this information when ChangeStreamFormat is called because
>
> the stream format does not tell anything about the buffer size at
>
> render time. SetMaxFramesPerSlice does not do it either. The value I
>
> receive here is 1156 (which is a default value set somewhere in the
>
> SDK
>
> code) while the size I've chosen in the Audio panel is 256.
>
> GetLatency is called after Initialize if the AU is actually used in a
>
> track and before a call to the render callback. The earliest time I
>
> get
>
> the information I need (the size of the render buffer and therefore my
>
> true latency) is the first call to my render callback, so I cannot
>
> return here a valid value. That's the reason why I was considering
>
> using the notification mechanism to tell the host what is my latency.
>
> If some special constant was defined, such as kAULatencyIsOneBuffer,
>
> this is the value I'd have returned to the host in GetLatency. If
>
> anyone has a better idea, I'll take it :))
>
_______________________________________________
>
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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.