Re: Why is CoreAudio C++ not Objective-C?
Re: Why is CoreAudio C++ not Objective-C?
- Subject: Re: Why is CoreAudio C++ not Objective-C?
- From: Brian Willoughby <email@hidden>
- Date: Tue, 19 Oct 2010 21:18:38 -0700
On Oct 19, 2010, at 20:50, Chris Share wrote:
I'm just about to embark on some AU programming (porting a Windows
VST plugin to
AU).
I'm curious as to why CoreAudio contains C++ and is not entirely
Objective-C?
It took Apple a decade or more to fully accept ObjC, because not
every developer came from NeXT. The CoreAudio development effort
started at least three years before Mac OS X was released, and
certainly long before ObjC was fully understood by the company at large.
Keep in mind that the Cocoa UI for AudioUnits is only a somewhat
recent addition, or so I recall. Originally, AudioUnits seemed to
only support Carbon, and thus there was no ObjC at all in CoreAudio
except for the non-CoreAudio parts of a host application.
There is a long-running myth that the runtime environment of ObjC is
"slow" while the runtime of C++ is "fast." This should be taken with
a grain of salt, since OpenStep had a shipping kernel driver system
written with Objective-C back when machines ran in the ballpark of 33
MHz to 100 MHz, and this driver model handled real-time audio without
dropouts (see NXSound). Dean Reece and crew tried to bring this
object-oriented driver model to Java around the time of the NeXT to
Apple transition, but Java was not up to the task, and that non-Apple
project was canceled. WWDC meetings in the 2001 era explained that
ObjC could make function calls with fewer CPU cycles than C++ DLL
functions under Win32, and this was when Apple was shipping Mac OS X
Server 1 for both Intel and PowerPC, i.e., long before Aqua.
I'm not sure why ObjC was not used for CoreAudio, except that C and C+
+ are more accessible while ObjC is not available on many platforms.
I don't know why availability matters when CoreAudio is not available
on any platform where ObjC is not available, but perhaps the
prospective third-party developer market was considered. I believe
that Dean Reece may have worked on CoreAudio, or perhaps consulted,
but you'd have to ask him - I assume he has the experience to compare
the available languages and their capabilities. Of course, the
reasons for the design choices may have nothing to do with the actual
language capabilities.
Brian Willoughby
Sound Consulting
P.S. One beauty of the Objective-C DriverKit in OpenStep was that
common vendor-supplied superclass code was provided by system
Frameworks. Thus, if there was a bug in your driver that was NeXT's
fault, they could ship a fix in an OS update, and then your driver
would benefit from the bug fix without even needing to be
recompiled. Third-party code was smaller because of Frameworks, and
the vendor's (NeXT's) sample code mistakes were not propagated into
the source code of every derived project. Yes, this approach was
fragile in certain ways. In contrast, the problem with CoreAudio -
and particularly AudioUnits - is that a bug in a single line of
sample code in the AU classes gets copied by every developer who
releases an AU, and that bug must be fixed separately by each
developer (some of whom may have gone out of business) after it has
been discovered. There's also a lot of duplicated source code
compiled into CoreAudio applications built on C++. But there are no
easy solutions, since ObjC Frameworks are fragile in a way that is
not entirely dissimilar to C++ libraries that have been compiled by
different versions of GCC (and thus have a different ABI).
_______________________________________________
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