CoreAudio
About CoreAudio™ Technology
CoreAudio is Apple® Computer’s technology standard for interfacing applications to multichannel audio hardware with professional quality. Apple defined the standard and made it the primary interface for audio in OS X. It provides the mechanism for making high-resolution, multi-channel, low-latency connections between audio hardware and audio applications on Mac OS X.
All Mac OS X computer applications provide support for communicating with audio hardware via CoreAudio. As such, it was the natural standard for Metric Halo to support for interfacing with Mobile I/O. Applications (programs) that communicate with hardware via CoreAudio drivers are called CoreAudio Hosts.
The CoreAudio standard is quite rich and provides a number of places where host applications may or may not properly support the specification. There are some hosts that were implemented early that did not get support for multichannel/multistream devices implemented correctly. Most of these hosts have been fixed or are in the process of being fixed now. If you encounter any problems with specific hosts, please let us know about it – but also please let the host vendor know about it. CoreAudio puts many more requirements on hosts than it does on drivers, so it is very likely that any such problems are in the host.
Metric Halo has done extensive testing with the major CoreAudio hosts, and some of the minor ones, and has worked to ensure maximum compatibility with all hosts. Even if you are using a host that is not specifically discussed here, you are unlikely to encounter problems. If you do, please file a bug report with both Metric Halo and the developer of the CoreAudio host. Please send bug reports to support at mhsecure.com with the subject MIOBUG Report.
CoreAudio Basics
How The CoreAudio Driver Works
The Mobile I/O CoreAudio driver is provided by Mac OS X KEXT. The KEXT is a Mac OS X kernel extension. This extension enhances the Mac OS operating system to provide support for communicating with the Mobile I/O hardware. The Mobile I/O driver is implemented as a KEXT due to the requirements of CoreAudio.
The KEXT is provided in a Mac OS X bundle called “MobileIODriver.kext”. This bundle is installed in the /System/Library/Extensions folder. Since this folder is managed by the system, you will have to have administrator access on the computer to install the driver.
The CoreAudio driver provides the required information for CoreAudio to discover and control Mobile I/O. Once the driver has been installed, CoreAudio will automatically find Mobile I/O units as they are attached to the computer and will publish the availablity of the hardware to all interested CoreAudio hosts.
CoreAudio is inherently a multiclient interface — more than one CoreAudio host can communicate with the hardware at the same time. Mulitple hosts can recieve the audio from a Mobile I/O at the same time, and multiple hosts can send audio to the Mobile I/O at the same time. When multiple hosts send audio to the hardware at the same time, CoreAudio will automatically mix the audio before it is sent to the Mobile I/O.
While this mutlticlient operation is a very cool feature of CoreAudio, and can be very helpful for many operations, you must be careful about unintended interactions. In particular, it is very easy to set up the system such that sounds from programs like email clients and other productivity tools will be mixed into your main audio stream (this happens when you set up the default audio output path so that you can use iTunes with the Mobile I/O). If you are not careful, you can check your mail and have the “Mail recieved” sound printed into the bounce that you are doing in the background.
CoreAudio Transport And Sample Rates
CoreAudio supports a wide variety of audio transport standards. As a practical matter, CoreAudio supports multichannel transport of 24 bit audio via floating point streams at virtually any sample rate. Many hosts only support a small number of sample rates and may not support all of the sample rates that are available with the Mobile I/O hardware.
Channel Names
CoreAudio provides a mechanism for the driver to tell the host the names of the channels. Some hosts do not use this information and “make up” their own names for the channels. This mechanism is not dynamic, so the Mobile I/O driver cannot update the host’s names as you adjust the Output Patchbay router or mixer channel assignments.
In v.5 the driver reports stream names to the CoreAudio host for both input and output. Since all I/O in the Mobile I/O is routed by you, you can refer to the names in your application and in MIO Console — they will match. Inputs are called FW 01, FW 02, …, FW 18, and outputs are called DAW 01, DAW 02, …, DAW 18.
Channel Enables
CoreAudio supports enabling and disabling audio streams. This is a relatively new feature of CoreAudio, and many hosts do not yet support it. It is not clear exactly how the user would control this functionality at this time. For applications that provide manual control over enabled channels, you will get the best performance if you only enable the channels you need. For applications that automatically maintain the enabled channels, you will get the best performance if you only assign channels to outputs you really want to use, and only record enable channels that you intend to record on.
CoreAudio Buffers
Audio channels are transported individually to the host in buffer sized chunks. The size of the audio buffers has an effect on the CPU load of the audio application, as well as the round-trip latency from input to output when the audio is routed through the host application for monitoring or processing.
Generally, the CPU load increases as the buffer size decreases. On the other hand, the latency decreases as the buffer size decreases.
Since, in general, you want the lowest CPU load and the lowest latency, you will have to make trade-offs.
The mixer engine in Mobile I/O helps substantially with this issue, because for the common critical monitoring configuration (monitoring while tracking external sources), the Mobile I/O mixer removes all of the computer transport latency from the monitor path and allows you to decouple the latency from the buffer size.
In the case that you are trying to perform with a softsynth running in your host, Mobile I/O’s mixer does not help decrease the latency since the signal is being generated on the computer. In this case you’ll want to minimize the output latency by selecting the smallest CoreAudio buffer size possible. This will depend on your computer hardware, the amount of processing you are doing, and the CoreAudio host you use. The MIO CoreAudio driver has been optimized to support extrememly small buffer sizes (down to 32 samples on Intel-based HW) and best-in-industry safety offsets.
Setting The CoreAudio Buffer Size
The methods used to set the CoreAudio buffer size will vary from host to host. Some CoreAudio hosts provide direct controls for adjusting the buffer size and others do not. If your host does not support setting the buffer size directly, you will have to use the host’s default buffer size.
Sample Size
The Mobile I/O CoreAudio driver provides the CoreAudio host with 24-bit samples in 32-bit floating point streams. It is the responsibility of the host to dither the incoming audio to 16-bit samples before recording them, if you record 16-bit. If the host does not dither the samples to 16-bit, they will be truncated by the host when they are recorded. For best recording quality, use your host’s 24-bit recording option.
Clock Sources
The CoreAudio specification provides the capability for hosts to control the hardware clock source. Some hosts provide a user interface to do this, others do not. If the host does provide an interface to do this, you will be able to select one of the Mobile I/O external clock sources directly from the host. If the host does not provide an interface, you will need to use the MIO Console to select the external clock source. If you have selected an external clock source using either the host or the console, you will not be able to control the system sample rate from the computer. MIO Console will automatically reflect the clock source and sample rate set by the host.