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 13:41:46 +0100
Am 26.11.2011 um 01:20 schrieb Kyle Sluder:
> On Fri, Nov 25, 2011 at 3:51 PM, Stefan Gretscher
> <email@hidden> wrote:
>> 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.
>
> Huh? Render callbacks execute in a hard-realtime thread. These threads have even higher priority than the kernel(!). The scheduler will
> preempt your thread when your slice is up, whether you like it or not.
>
> The hard upper bound is specified when the realtime thread is created:
> http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
>
> These parameters will almost certainly be specified to provide minimum latency between the software and the hardware. Failure to fit
> computation within the real-time window will therefore almost certainly lead to glitching; there isn't any slack for your computation to spill over into.
You got me all wrong here. My point was that no assumption can be made that just because a given Audio Unit is in "realtime render mode", it completes its processing within the time corresponding
to the buffer size for each render call, which is what Heinrich seemed to suggest. There is nothing in the Audio Unit specification justifying this claim, and violating this constraint is valid behavior.
Realtime render mode just means "try to complete in realtime", so it imposes rules like "no locks", "non-blocking calls only", "no memory allocation" etc., but it does not provide any guarantees that
the actual realtime boundaries will be met for any given render call.
Which is why many hosts use pre-rolling of some sort and render plug-ins ahead-of-time if possible (hopefully serving kAudioUnitProperty_PresentationLatency properly...).
And while it's certainly common to render plug-ins from realtime threads, there is no rule requiring this, and some hosts do successfully use different threading schemes.
See for example the earlier post by David about a possible different approach.
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