Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- Subject: Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- From: Brian Willoughby <email@hidden>
- Date: Tue, 22 Nov 2011 21:10:26 -0800
On Nov 22, 2011, at 06:19, Heinrich Fink wrote:
The only safe assumption would seem to be that you can either use
OfflineRender exclusively, or Online Render. In either case, your
safest bet would be to issue a Reset() call to clear any possible
invalid state in the AU, and then use a single mode only.
Calling AudioUnitReset in between is not a viable option,
unfortunately. This would, for example, cut off a delay effect
while switching between an offline preroll and the following
realtime feed, which obviously is not desirable.
Exactly my point. The only safe assumption is not useful to you,
thus you have no viable option.
In the ideal case, we would not even have to distinguish between
preroll and realtime feeds since audio units render only relative
to sample time and not CPU time (as you mentioned).
Since the design goal of the OfflineRender property is to increase
the render quality, I see no reason that you would need your preroll
audio to be rendered to a higher quality than the realtime audio.
Basically, you should run everything at Online Render quality and
just call that good enough.
In other words, your goal all along has been to achieve higher
rendering speed during preroll, not higher rendering quality. Since
OfflineRender does not increase rendering speed (but more likely
slows it down in most cases where it makes any difference at all),
then it seems like your application would want to specifically avoid
OfflineRender (unless I missed something).
Brian Willoughby
Sound Consulting
_______________________________________________
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