Re: Does anybody implement 'reset' in their Instrument Audio Units?
Re: Does anybody implement 'reset' in their Instrument Audio Units?
- Subject: Re: Does anybody implement 'reset' in their Instrument Audio Units?
- From: Jim Wintermyre <email@hidden>
- Date: Tue, 2 Mar 2010 12:35:39 -0800
Actually, you can know this with the AU spec
Two ways:
There are two properties that an AU should report about its
processing, tail time and latency. Tail time we have described as
being a conservative property (whereas latency should be accurate).
Tail time is the time that it takes for you audio to go silent after
the last real input has been presented to the AU - basically a
reverb/delay decay time
So, as a host you see this:
1st sample in -> appears in the output latency samples later
(the first latency number of samples out are silent)
last sample in -> you still have latency + tail samples within the
AU that need to be "pulled through"
(feed in latency + tail samples of silence)
If you want to align sample edges as a host, you would discard the
latency samples of an audio unit from its output after the AU has
been reset (or initialised)
If you want to pull out all of the samples of an AU, you need to
feed latency+tail number of samples into the AU. You will get back
latency + tail samples (you already had to throw out latency samples
at the start, so you need to get these back "after" the last sample
of input)
The latency value is essential for proper host operation (automatic
delay compensation). The tail time is perhaps a little less useful
IMO. Why? Because in many cases the tail time changes as parameters
are adjusted (eg. reverb decay), and in some cases the tail time
might not even be known (eg. resonant filter). So a host would have
to query this value whenever a parameter in the plugin changes, and
also properly deal with essentially infinite tail times.
The auprocess example we shipped for a while did this with effects
(there are some additional notes in that example you can read if you
are interested)
For a AU host, you can use these numbers to load balance your
plugins - once they have gone past an active segment, you can use
these numbers to know how much additional data you need to pull
through them. Once you have done that, any further "rendering" by
that AU is wasted CPU cycles until you have new data to give it.
Both Logic, STPro/FCP use these numbers to handle their rendering
(as does QT actually), so many of the initial problems we had with
these properties have been shaken out now.
In my experience, Logic does NOT observe this, or at least does not
use this as its sole technique for detemining when to stop calling
plugins. I know this because we essentially report infinite tail
time in some plugs for reasons mentioned above, but yet we see that
Logic does still stop calling our plugins at some point anyway,
basically when it thinks the plugin output is silent. I assume that
it is measuring the plugin output, maybe using the track metering
level and assuming some cutoff for being inaudible.
Also, I recall that in DP (at least in an older version, maybe 4.6,
dunno if this is still the case), if the reported tail time was very
large (like more than the number of seconds in a day), it is ignored
and the plugin is always called.
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. :)
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