On Mon, Mar 1, 2010 at 4:03 AM, Greg Parker <gpar...@apple.com> wrote:
> On Feb 28, 2010, at 7:24 PM, Erik Buck wrote: > > I disagree. I have written very low latency device drivers in > Objective-C. Why do you think Objective-C has too much "latency" for audio? > When properly used, Objective-C programs are no more likely to be preempted > than any other kind of program. Message dispatch generally has constant > time and is only 2.5 times the cost of a C function call. There aren't many > function calls or messages sent in audio processing anyway. Signal > processing routines tend to be long loops. Objective-C _IS_ C which means > it is likely usable in any situation where C is usable. > > Message dispatch is generally fast. For many real-time-ish purposes that's > good enough. But occasionally message dispatch (1) takes much longer, and > (2) acquires locks. For some real-time-ish purposes, this sort of surprise > is fatal when it occurs. Since there's no way for the program to control > when dispatch is fast and when it is slow, clients with sufficiently tight > "no surprises" requirements should avoid it altogether. If your requirements > are demanding enough that you can't call malloc(), then you probably can't > call objc_msgSend() either. > > It's the locks that kill. With care, a real-time-ish thread can pretty much > solve problems of page faults and scheduling and the like. But the moment > you take a lock, you're at the mercy of some other thread that may not be so > careful. > > Audio clients tend to be the most paranoid about this on Mac OS X. They're > the closest to truly-real-time requirements that I see, with good reason: if > your audio playback skips, ever, you probably just lost a customer. > Just for those who haven't already noticed this interesting detail, audio is more constrained than video. If your movie skips a frame? You probably cannot tell. If your audio drops? Urgh! -Ken > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
