Re: Do I really need to steer clear of Objective-C when providing data for RemoteIO?
Re: Do I really need to steer clear of Objective-C when providing data for RemoteIO?
- Subject: Re: Do I really need to steer clear of Objective-C when providing data for RemoteIO?
- From: Kyle Sluder <email@hidden>
- Date: Fri, 7 Jan 2011 10:11:28 -0800
On Fri, Jan 7, 2011 at 10:03 AM, Gregory Wieber <email@hidden> wrote:
> That kind of ignores the point of everything else I wrote, and is splitting
> hairs on wording. The word 'overhead' was meant to refer to any and all
> performance issues related to using objective-c in a render callback.
As Greg Parker points out elsewhere, the actual cost of objc_msgSend
is quite low.
But really, what does it get you? The tasks that need to be performed
within a render audio callback are very well-defined and narrow in
scope. Brian Willoughby hit the nail on the head. Since you can't pass
an Objective-C method as a render callback anyway without building a C
trampoline, there's really no reason not to architect your audio
engine in such a way that it's possible to avoid Objective-C from
within the render callback.
By all means, use ObjC to do audio processing. Just do it outside of
the render callback context and make it possible to get at that data
without taking a lock or stalling when Core Audio needs it.
--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