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: Sat, 26 Nov 2011 00:51:53 +0100
Am 25.11.2011 um 16:33 schrieb Heinrich Fink:
> In other words, I would consider AudioUnits to operate properly under "short-term-real-time" characteristics: each render call must not take longer than the realtime duration of the requested samples.
Where do you draw this conclusion from? It's no reasonable assumption at all. There is no upper bound defined for how long any single Audio Unit render call may take to complete.
These sorts of requirements usually are only established on dedicated DSP systems, where the entire hard- and software setup is well-known.
Given the various cache effects and the concurrency with other programs and the OS, the actual execution time cannot be predicted reliably on general purpose Macs.
Thus, plug-in vendors just make their code as fast as they can and hope the user machines have enough horse power. If that's not the case, there's drop outs.
> Other more unstable systems might only meet the real-time constraint over a longer period of time (e.g. during a 2 sec preroll buffer).
Generally speaking I'd consider this is true for Audio Units too.
For example FFT-based effects typically collect samples until enough data is available to process an entire FFT block, which is then done entirely in one processing call.
The results are buffered and the following processing again merely copy data between the buffers until another CPU-intense FFT block is available and so on.
If the render block size is smaller than the FFT size (which it usually is), then you'll see those calls that only read and write the buffers return very quickly, and
those that do an FFT and the according frequency-domain-processing take much longer, maybe even longer than real time.
In this case you'll need external buffering of at least the FFT block size for the system to work without glitches, which is why most DAWs allow the users to adjust this
rendering buffer size as needed in the given use case scenario.
Best,
Stefan
_______________________________________________
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