Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- Subject: Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- From: Stefan Gretscher <email@hidden>
- Date: Tue, 22 Nov 2011 19:45:23 +0100
Hi Heinrich,
Am 22.11.2011 um 15:19 schrieb Heinrich Fink:
> 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).
>
> This is with the exception of AUFilePlayer, of course. I would still love to hear some comments about AUFilePlayer and its offline (in)capabilities. It seems strange to me that file streaming to audio is not able to catch up with faster render requests.
From a plug-ins point of view, offline rendering means that the rendering is no longer required to meet the usual realtime constraints.
This has a lot of implications, in particular when a plug-in does file I/O: if the data cannot be loaded fast enough in a realtime context, then the plug-in needs to implement some fallback (usually using silence instead of the actual file data). However in offline mode, it can instead simply wait until the data is available.
Thus, enabling offline mode is a good idea whenever realtime is not needed because it creates more robust/reliable output data.
Note that the emphasis here is not on telling the plug-in that rendering calls will be made faster (or slower, for that matter) than real time, but rather how to deal properly with CPU or I/O overload situations and/or how to tweak any plug-in internal scheduling to avoid overloads in the given usage scenario.
Am 22.11.2011 um 15:19 schrieb Heinrich Fink:
>> I have a hunch that, rather than needing some means to determine whether an AU support non-real-time rendering, what you really need is some means to determine whether it is safe to assume that you can mix offline and online rendering from one call to the next without producing an invalid state.
>
> Switching between offline and online mode flawlessly is a premise that I just assumed to be possible, at least when assuring that the "context switch" happens only in between render calls. Of course you are right that this might not always be the case.
I would argue that for the above reasoning all plug-ins that choose to support kAudioUnitProperty_OfflineRender must also handle toggling between realtime and offline rendering properly without getting stuck in invalid states, and that it is correct and required for a host to toggle this accordingly when implementing a pre-rolling as discussed earlier in this thread.
I would also argue that the host would be responsible for making sure it doesn't toggle this property while calling the rendering from another thread at the same time.
That all said, just like Brian I am not aware that any of this is explicitly stated in the documentation, so current plug-in implementations may behave differently.
Best,
Stefan Gretscher
_______________________________________________
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