Re: Number of frames in Render()
Re: Number of frames in Render()
- Subject: Re: Number of frames in Render()
- From: Doug Wyatt <email@hidden>
- Date: Mon, 17 Jul 2006 17:42:46 -0700
On Jul 17, 2006, at 13:08 , John Allsup wrote:
The parameter inNumFrames passed to Render() appears to change very
rarely.
e.g. on AULab it seems to be constant at 512 and in Live it seems
to be constant at 128 if I recall correctly. When exactly does the
inNumFrames value change and can it be assumed to be constant
between initialisations of an audio unit?
If it can change (i.e. an Audio unit may be asked to render 512
frames, then 128, then 417) what is gained by this in context of
the design of the AU framework?
The prime example is that you can run an AU processing chain at a
different sample rate than the hardware, through a rate converter,
while still rendering as close to realtime as possible.
Other more obscure situations:
Some hosts implement sample-accurate automation by rendering the
samples before and after a parameter change with separate render
calls (this is inefficient and it's better to let the plug-in handle
this, but nothing in the spec forbids it).
A host might be in some kind of offline rendering mode (e.g. freeze
or bounce) and pass an AU relatively large buffers until it has some
leftovers at the end. The host can then just ask the AU to render the
leftovers.
Doug
--
Doug Wyatt
Core Audio, Apple
_______________________________________________
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