Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- Subject: Re: Preroll semantics & clarification of kAudioUnitProperty_OfflineRender
- From: Kyle Sluder <email@hidden>
- Date: Fri, 25 Nov 2011 16:20:47 -0800
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.
--Kyle Sluder
_______________________________________________
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