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: "B.J. Buchalter" <email@hidden>
- Date: Thu, 21 Oct 2010 01:46:48 -0400
On Oct 21, 2010, at 12:47 AM, Christopher Penrose wrote:
>
> I disagree with Brian. I began coding Objective-C on the NeXT in 1990 and I have finally accepted that vanilla use of the Objective-C runtime is not appropriate for low-latency real-time audio systems. I haven't tried it yet, but there may be some interesting ways around the latency of message binding in the run-time as suggested in articles like this: http://it.toolbox.com/blogs/macsploitation/bypassing-objectivecs-message-passing-mechanism-for-speed-24946
>
> I have minimal C++ experience, a general dislike of its inelegant syntactical heft, but I really don't believe it was purely provincial preference that C++ was used in parts of CoreAudio. It pains a part of me to say it, but It is better suited to the task of AudioUnits than Objective-C. A computer language has its strengths -- a dynamic language is a higher latency language by design. The important question: does the additional latency matter? I have found in many real-time applications that it does.
>
> It would be nice, however, if examples did not use C++ (or Objective-C for that manner) when not necessary. While I have been writing nothing but Objective-C for months for my current project, all of my direct audio code is written in c99. There are a few SDK examples that had useful code written in C++ unnecessarily that required translation. Despite Apple's best efforts the egregious namespace schism of Objective-C++ is something my company avoids like the plague. But we will have to have a few .mm files I guess if we venture into custom AudioUnit design for some project. It makes sense to me that an example demonstrating a c99 interface should be written only in c99.
Just to add to this:
As Christopher notes, CoreAudio is a C API, not a C++ API. A bunch of utility and sample code that Apple ships for CoreAudio is C++, but you don't need to use C++ in CoreAudio if you don't want to. Even with AudioUnits, the API is actually C built on the ComponentManager. The C++ is just a set of wrapper classes that implement the correct semantics for the API. But one could just as easily write an ObjC version of the wrapper classes to implement an AudioUnit.
I suspect that the C++ is simply because the CoreAudio SDK and AudioUnit wrapper classes were written before (a) apple had decided once and for all that ObjC was the way forward, and (b) 99.999999% of all commercial audio applications and plugins were written for Carbon and C++, and making it ObjC would have probably doomed the effort.
If CoreAudio/AudioUnits were being introduced today, I would venture to guess that the wrapper classes would be ObjC.
That all being said, there is still an issue with the ObjC run time in realtime threads. It is not that it is slow; it is that it has unbounded latency for message sending (due to caching and lookups; the objc message sending mechanism has a lock and can allocate memory). It has been stated by Apple engineers multiple times that ObjC message passing (as currently implemented) is not suitable or reliable for real-time threads (like the IOProc thread in CoreAudio). So even if the wrapper classes were written in ObjC, the processing code would still have to be implemented in pure C function with no message passing. C++ does not have this issue -- you can have virtual functions and they can be called within the IOProc/AudioUnit processing routine. So one concern with an ObjC framework is that you can't rely on the Object part in your processing code -- that could be very limiting. If you did, it might seem to work, but it would not be reliable due to the unbounded nature of the runtime.
Best regards,
B.J. Buchalter
Metric Halo
http://www.mhlabs.com
_______________________________________________
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