General OSX confusion: that’s what we see out there in the music industry. This new Mac operating system is a pretty significant departure from its predecessors, and thus has caused a lot of confusion, especially in the Mac community. A common question we hear is, “Why is it taking so long for developers to get their products working under OS X?”
Sweetwater Sales Engineer Shawn Parr steps in today to shed a little light on things.
OS X is Apple’s newest operating system and it includes a lot of new and different technology from any Macintosh system before. Along with that come new buzz words and concepts.
One of the major differences between OS X and previous Mac operating systems is the Kernel. Every OS has a Kernel, it is the very core of the system that takes care of assigning what goes where in memory and what code gets to run on the processor for what amount of time. In OS 9 there is a ‘nano-kernel’ which is simplified and only handles very basic tasks. When you get into multitasking it only breaks time down between necessary system tasks and applications. It is up to the programmers who write the applications themselves to determine how much time the application will use, and how much it will let other applications run. This system is known as ‘Cooperative Multitasking.’
OS X’s kernel is based on the Mach micro-kernel, and is a bit more advanced. It handles all scheduling for any system function or application. No matter how applications are written they can not hog resources unless the kernel allows it, and if you need something to do something else while one application is being a hog the kernel will take time away from it to get your task done. This can be a good or a bad thing; if you are trying to record 64 tracks of audio and click on your email, depending on how the kernel handles these tasks, you could lose some audio. Luckily there are priorities that can be set, and they help determine if something should be allowed to stay a hog at specific times. This system is known as ‘Pre-emptive Multitasking.’
Now all of this is really cool, but why is it taking so long to see applications, especially audio applications on OS X? Well there are two reasons for this.
One is what is known as ‘Abstraction Layers.’ In OS 9 any application or function can directly talk to any piece of hardware plugged into the computer. This is very convenient for programming, but can lead to some problems if you have a bug in some software, if it accidentally says the wrong thing to the wrong piece of hardware your machine could act weird, or crash. OS X is broken up into different layers. You have:
Hardware – the actual machine
Kernel – basically the operating system, referred to as Darwin
Application Environment – this includes Cocoa, Java, Carbon, and Classic
GUI – the Graphical User Interface
In OS X, each layer is only allowed to talk to the next layers. Applications running in Carbon, Classic, Java, or Cocoa are not allowed to talk to hardware, only the kernel is. Carbon, Java, and Cocoa are environments for writing programs that run in OS X natively, or fully featured. Classic is an environment that allows you to run OS 9 applications in OS X, but without the full functionality of other OS X applications, and they have to follow the rules for the abstraction layers. Since most MIDI and Audio applications for OS 9 talk to hardware directly, they do not work under OS X even if in the Classic environment because it just isn’t allowed.
How you get around this is by writing a kernel driver for your hardware. To be really general these are similar to extensions in OS 9, but programmers do have a lot of work to do to set them up properly. Once you have a kernel driver running your software can talk to that driver, which in turn handles communication with your hardware. This is very similar in concept to how Protools and DAE work [Ed – used to work, in the pre HD Pro Tools world].
The Second issue has to do with how programmers write code. Most operating systems have what are called API’s, or Application Programming Interfaces. These are parts of the OS that will do basic work for a programmer that needs to be done for every program. Some of these functions are working with memory, creating windows, and reading and writing to disk. With OS X there are a few environments, as stated before. Cocoa is completely new, with new API’s for programmers to learn to write for. Carbon is a stop-gap that contains OS 9 API’s that work under OS X, but not all of the API’s from OS 9 made it into the Carbon specifications. Apple decided to throw out a lot of dead weight with Carbon, and as such anyone who was using those API’s must find a way to rewrite their programs without them in order to run under OS X.
So once you take these two issues and add them together you can see why it would be quite a bit of work to get an audio application to work under OS X, not only do you have to completely rewrite the application itself, but you need to create or find a way to communicate with any hardware involved. Then there is another component, known as CoreAudio, but that will be a whole discussion of its own sometime in the future.
