Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- Subject: Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- From: Paul Davis <email@hidden>
- Date: Mon, 21 Nov 2011 11:55:37 -0500
On Mon, Nov 21, 2011 at 11:49 AM, Heinrich Fink <email@hidden> wrote:
> Hi,
>
> I am currently designing an audio engine for a broadcast application based on the AudioUnit and AUGraph APIs. It's basically file-based audio input, a bit of routing plus some filtering effects. We might have to use a different output path than the usual (preferred) way of using the AUHal. This has been discussed previously here: http://lists.apple.com/archives/coreaudio-api/2011/Nov/msg00077.html - and is not the issue of my question. To quickly sum up the previous discussion: we get a callback from a broadcasting card's SDK to fill buffers with audio data (e.g. Blackmagic UltraStudio 3D). In order to make this work, we will not use the AUHal approach, but rather call the audio graph by ourselves.
>
> The crux of the matter is the following:
>
> Before playback starts, we have to fill hardware buffers as quickly as possible during a "preroll" phase. This should be faster than realtime, it is basically offline rendering of the AUGraph for about 2 seconds. After the desired watermark level of the hardware buffers has been reached, the callback semantics change back to realtime behavior (similar to being called by the AUHal).
>
> According to the documentation and related discussions on this mailing list, I understand that a render context like "preroll phase" would require the property kAudioUnitProperty_OfflineRender to be supported by each audio unit in the graph, and to be set to "true". This works under the assumption that if kAudioUnitProperty_OfflineRender is not supported by an audio unit and is not set to "true", then I must not call AudioUnitRender faster than real time, i.e. correct behavior of the audio unit would not be guaranteed anymore.
As usual, its not (well) documented, but as a host implementor I can
tell you that this absolutely not my interpretation of that flag. My
reading is that it exists to tell the plugin "we are not rendering in
realtime mode, so if you want to take extra time for any reason, you
can". Nothing more, or less.
If anyone has any evidence that this interpretation is wrong, I'd love
to hear about it.
>host implementations just ignore setting this property and assume that AU effects would be fine being called faster than realtime? It is understandable that units
I certainly assume that I can call any AU as rapidly as I want.
_______________________________________________
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