Re: Cocoa-Heavy Audio Unit
Re: Cocoa-Heavy Audio Unit
- Subject: Re: Cocoa-Heavy Audio Unit
- From: Brian Willoughby <email@hidden>
- Date: Tue, 31 Jan 2006 16:21:17 -0800
William Stewart <email@hidden> wrote:
[snip]
[ I think that this might also be worth a topic of further discussion -
[ might as well put the cat amongst the pigeons.
[
[ We've discussed with a number of people the suitability of using ObjC
[ for real-time (or better, time-constrained) implementations... It has
[ made us nervous, given that ObjC message sends are treated as an
[ opportunity for the ObjC runtime to re-evaluate its world, and thus
[ can not only involve locks, but also memory allocations. I would be
[ extremely concerned and extremely cautious about using ObjC in this
[ manner; for a view it is excellent of course. I'm sure others would
[ have a point of view about this...
NEXT based the entire DriverKit on ObjC. This is the precursor to IOKit, and
ran on NEXTSTEP for Intel, SPARC, and HP PA-RISC processor platforms. (They
never did back-port it to the Motorola 680x0 processor version of NEXTSTEP,
though.)
I have written display drivers, network drivers, and several audio drivers for
DriverKit. I never experienced any stuttering of the display or dropouts of
audio. I imagine that network drivers might be more forgiving of random
delays, but the audio drivers would not have been.
All drivers inherited from ObjC classes that were provided in object form with
the system, not in source form with the DriverKit SDK. An advantage of this
is that errors in NeXT code could be fixed with new system releases, without
requiring that every third-party driver be compiled against a new SDK to
benefit from corrections of NeXT's mistakes.
Perhaps DriverKit drivers were a little more predictable than an AudioUnit
with UI. Perhaps the ObjC method cache was always primed before timing
critical calls were made. I do not believe there was any technical reason for
divorcing ObjC to transition from DriverKit to IOKit, just political reasons
for Apple engineers to fear the unknown.
At the 1997 WorldWide Developers Conference, Apple was trying to encourage
development for Rhapsody, the direct port of NEXTSTEP for PowerPC Macs, which
happens to use the ObjC DriverKit. Apple engineers who were former NeXT
engineers gave the WWDC talks, and had all kinds of benchmarks on the overhead
introduced by ObjC. IIRC, the timings were less than segment-loading traps on
Intel which were required (at least at that time) for any function call which
crossed a DLL boundary. In other words, ObjC method calls were faster than C++
DLL calls in 1997. No idea whether that still holds with modern processors
and compilers.
There are issues with the ObjC runtime not being fully re-entrant in the early
NeXT implementations. I believe the runtime now adapts semi-automatically to
re-entrant usage and implements locks as needed. This could pose problems for
AudioUnits. However, there are ways to expose the caching mechanisms of ObjC
(using @selector to call methods by address without the lookup) which might be
useful to alleviate some of the randomness. Not sure what to do about the
runtime locks without some experimentation.
It would be nice if someone (with a lot of time and intimate knowledge of
AudioUnits) were to recreate the entire C++ class hierarchy of the AudioUnit
SDK using ObjC. Then, a framework could be distributed so that every
ObjC-based AudioUnit would not need to be recompiled every time the SDK sees
bug fixes. Not bloody likely that this amount of effort will be taken any time
soon, but it is nice to see people considering the heavy use of ObjC in
AudioUnits - this can only pave the way for more.
Brian Willoughby
Sound Consulting
_______________________________________________
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