Core Audio のプログラミングインターフェース [のふ処|NOFUDOKORO]

この文書は読取専用です。文書のソースを閲覧することは可能ですが、変更はできません。もし変更したい場合は管理者に連絡してください。
<WRAP rightalign>原文 [[https://developer.apple.com/library/mac/documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatsinCoreAudio/WhatsinCoreAudio.html|Core Audio Overview: Core Audio Programming Interfaces]]</WRAP>

====== Core Audio のプログラミングインターフェース ======

Core Audio は、Mac OS X の全てのオーディオ関連の仕事を扱う包括的なサービスの集合体で、これは、たくさんの部分的な構成要素から成ります。
この章では、Core Audio の様々なプログラミングインターフェースの解説を行います。

本文章の目的は、**API** が単独のヘッダファイルにより定義されるプログラミングインターフェースである、ということを確認する一方で、**サービス** は2,3個のヘッダファイルにより定義されるインターフェースである、ということを確認することにあります。

Core Audio フレームワークと、それらフレームワークが持つヘッダファイルの完全なリストは、[[core_audio_フレームワーク|“Core Audio フレームワーク”]] をご覧ください。

===== Audio Unit サービス =====

Audio Unit サービスは Audio Unit の作成と操作を提供します。
このインターフェースは、関数、データ型、定数からなり、これらは AudioUnit.framework と AudioToolbox.framework に含まれる以下のヘッダファイルで定義されています:

  * AudioUnit.h
  * AUComponent.h
  * AudioOutputUnit.h
  * AudioUnitParameters.h
  * AudioUnitProperties.h
  * AudioUnitCarbonView.h
  * AUCocoaUIView.h
  * MusicDevice.h
  * AudioUnitUtilities.h (AudioToolbox.framework)

Audio Unit は、オーディオ信号を扱ったり生成したりするためのプラグイン、とりわけ Compornent Manager のコンポーネントです。
Multiple instances of the same audio unit can appear in the same host application. They can appear virtually anywhere in an audio signal chain.

Audio Unit は各ベンダのユニット間の互換性を確保するために、ノンインタリーブ32ビット浮動小数点値リニア PCM に対応しなければなりません。(この形式に加えて)他のリニア PCM の形式に対応しても構いません。
現時点では、Audio Unit はリニア PCM 以外のオーディオ形式をサポートしていません。
他の形式のオーディオデータをリニア PCM に変換するには、Audio Converter を使うことが出来ます([[audio:core_audio_概要:audio_converters_and_codecs]] をご覧ください)。

  メモ: Audio File サービスと Converter サービスは、独自ファイル形式の扱いやデータの変換に、
  Compornent Manager のコンポーネントを使用します。しかし、これらのコンポーネントは Audio Unit ではありません。

ホストアプリケーションは、Audio Unit の探索と読み込みの為に Compornent Manager コールを使用しなければなりません。
各々の Audio Unit は Compornent Manager タイプ、サブタイプ、製造者コードの組み合わせによって、一意の識別子が割り当てられます。
Compornent Manager タイプは、そのユニットの目的の概要(エフェクトユニット、生成ユニットなど)を表します。
サブタイプは、Audio Unit を一意に特定する、それぞれの製造者によって付けられる任意の値です。
例えば、あなたの会社がいくつかの異なるエフェクトユニットを提供する場合、各々のユニットは、他のユニットと区別がつくように異なるサブタイプを持つ必要があります。
Apple は標準 Audio Unit タイプを定義していますが、サブタイプはあなたの望むものを自由に付けることが出来ます。

Audio Unit は、自身の機能情報と設定情報を**プロパティ**を使って提示します。
プロパティはキーと値がペアになっており、Audio Unit のチャンネル数、サポートするオーディオデータストリーム、対応するサンプリングレート、カスタム Cocoa ビューをサポートしているかどうか、といった時間に関係のない(non-time)様々な特性を保持します。
それぞれの Audio Unit タイプは、Apple によって定義されているいくつかの必須のプロパティを持ちますが、あなたのユニットの要求に応じて、自由に追加プロパティを定義することもできます。
ホストアプリケーションは、ユニットのユーザーインターフェースを作るためにプロパティ情報を利用することが出来ますが、多くの場合 Audio Unit が、より洗練された自身の独自のユーザーインターフェースを提供します。

また Audio Unit は、その Audio Unit の機能に依存する様々な**パラメータ**も持ちます。
一般的にパラメータは、しばしばエンドユーザーがリアルタイムに調整できる設定を表します。
例えば、パラメトリックフィルタユニットは、センター周波数と適用周波数幅を決めるパラメータを持ち、ユーザーインターフェースを使って値を設定されるかもしれません。
一方で音源ユニットは、MIDI あるいはイベントデータの現在の状態を表わすのに、パラメータを使用します。

Audio Unit で構成される信号チェーンは、一般的に出力ユニットで終わります。
出力ユニットは、しばしばハードウェアとのインターフェースとなります(例えば AUHAL はこの種の出力ユニットです)が、これは必須ではありません。
出力ユニットは、データの流れを独立して開始・停止できるただ1つのユニットという点において、他の Audio Unit とは異なります。
標準的な Audio Unit はデータの取得に、"pull" メカニズムを利用します。
各々の Audio Unit は、オーディオチェーンの中でその後任者として、コールバックを登録します。
When an output unit starts the data flow (triggered by the host application), its render function calls back to the previous unit in the chain to ask for data, which in turn calls its predecessor, and so on.

ホストアプリケーションは、オーディオ処理グラフに Audio Unit をまとめ、より大きな信号処理モジュールを作成することができます。
処理グラフ中の結合ユニットは、そのチェーンをデータ流が通れるように、自動的にコールバックリンクを生成します。
更なる情報は [[audio:core_audio_概要:core_audio_のプログラミングインターフェース#オーディオ処理グラフ API|オーディオ処理グラフ API]] をご覧ください。

Audio Unit の状態の変化を監視するために、アプリケーションは、Audio Unit の特定のイベントが発生した際に呼ばれる "リスナー" というコールバックを登録することができます。
例えば、アプリケーションはパラメータの値が変更された時や、データ流が割り込まれた時を知ることができるでしょう。
詳細については [[http://developer.apple.com/technotes/tn2002/tn2104.html|Technical Note TN2104: Handling Audio Unit Events]] をご覧ください。

Core Audio SDK (の AudioUnits フォルダで)は、殆どの Component Manager プラグインを定義する C++ のフレームワークと共に、共通の Audio Unit タイプ(例えば、エフェクトユニットや音源ユニット)のテンプレートを提供します。

Audio Unit の開発、および SDK の使い方に関する詳しい情報は //[[http://developer.apple.com/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/index.html|Audio Unit Programming Guide]]// をご覧ください。

===== オーディオ処理グラフ API =====

オーディオ処理グラフ API は、Audio Unit ホストアプリケーション開発者が、オーディオ処理グラフの作成と操作を可能にします。
オーディオ処理グラフ API は AudioToolbox.framework の AUGraph.h ヘッダファイルで定義される、関数、データ型、定数からなります。

オーディオ処理グラフ(AUGraph とも呼ばれます)は、互いに繋がった Audio Unit の集合を定義し、特定の仕事を行います。
この仕組みのおかげで、信号チェーンへの挿入・削除が簡単にできる共通処理モジュールを、作成することができます。
例えば、グラフはいくつかの Audio Unit を繋ぎ、信号を歪ませ、それを圧縮し、そして音場の特定の位置に音を配置することができます。
グラフの終端を AUHAL にして、音をハードウェアデバイス(アンプやスピーカ)に送ることができます。
オーディオ処理グラフは、主に信号処理を扱うアプリケーションが、その処理をアプリケーション自身の実装によるものではなく、Audio Unit の連結により行うことを可能にするので、有用です。
Figure 2-1 は簡単なオーディオ処理グラフの例です。

**Figure 2-1** 簡単なオーディオ処理グラフ\\
{{audio_proc_graph_simple.jpg|簡単なオーディオ処理グラフ}}

オーディオ処理グラフ中の各々の Audio Unit は**ノード**と呼ばれます。
あるノードの出力から、別のノードの入力へくっつけることで、接続を行います。
Audio Unit の1つの出力を、複数の Audio Unit の入力に接続することはできません。複数の入力が必要な場合は Figure 2-2 のように、分割ユニットを用います。
しかしながら、Audio Unit はそのタイプによって、複数の入出力を持つことがあります。

**Figure 2-2** 正しくない接続方法と正しい接続方法\\
{{correct_incorrect_connections.jpg|}}

大きなグラフの中にサブグラフを組込んで、オーディオ処理グラフ API を利用することもできます。このとき、Figure 2-3 で示されるように、サブグラフはメイングラフの中では1つの単体ノードとして振る舞います。

**Figure 2-3** 主オーディオ処理グラフ中におけるサブグラフ\\
{{audio_processing_graph.jpg|主オーディオ処理グラフ中におけるサブグラフ}}

各々のグラフまたはサブグラフは、出力系の Audio Unit で終わらなければなりません。
サブグラフの場合は、その信号経路は標準出力ユニットで終わるべきであり、そして、そのユニットはどのハードウェアにも接続されません。

オーディオ処理グラフが未使用で Audio Unit をプログラム的に繋ぐ事が可能な限り、オーディオデータの処理中にグラフを動的に変更し、信号経路を変えることが出来ます。
加えて、グラフは単純に Audio Unit の相互接続と表わされるので、リファレンスから Audio Unit のインスタンスを作成することなく、グラフの作成と変更を行うことが出来ます。

===== Audio File サービスと Audio Converter サービス =====

Audio File サービスと Audio Converter サービスは、オーディオデータのファイルまたはバッファからの読み書き機能を提供し、多くの異なるデータフォーマット間での変換を可能にします。
このサービスは、関数、データ型、定数からなり、これらは AudioToolbox.framework と AudioUnit.framework に含まれる以下のヘッダファイルで定義されています:

  * ExtendedAudioFile.h
  * AudioFile.h
  * AudioFormat.h
  * AudioConverter.h
  * AudioCodec.h (AudioUnit.framework)
  * CAFFile.h

多くの場合、拡張 Audio File API を利用し、これが最もシンプルな、オーディオデータ読み書きの為のインターフェースを提供します。
この API を用いたファイルの読み込みでは、Audio Unit のネイティブ形式であるリニア PCM 形式へと、自動的に展開・変換されます。
同様に、オーディオデータの保存は、関数呼び出し1つでリニア PCM が(必要であれば他の形式に)圧縮・変換され、ファイルへ書き込まれます。
[[audio:core_audio_概要:supported_audio_file_and_data_formats]] は、Core Audio が標準でサポートするファイル形式の一覧です。
これら形式の中には、制約事項のあるものもあります。例えば、標準では Core Audio は MP3 ファイルの読み込みはできますが、書き込みは出来ません。また、AC-3 ファイルについてもデコードしかできず、さらにステレオへのみです(5.1ch サラウンドへは不可能)。

ファイルの読み書き、データ変換プロセス以上の制御が必要ならば、(AudioFile.h と AudioConverter.h の中の)Audio File API と Audio Converter API に直接アクセスすることができます。
Audio File API を使うと、オーディオデータのソース(オーディオファイルオブジェクトとして表わされます)は、実際のファイルあるいはメモリ中のバッファの何れかになります。
In addition, if your application reads and writes proprietary file formats, you can handle the format translation using custom Component Manager components that the Audio File API can discover and load.
例えば、ファイル形式が DRM を持つ場合、その処理を扱う為にカスタムコンポーネントを作成したいと考えるでしょう。

==== Audio Converter と Audio Codec ====

Audio Converter は、あるファーマットを別のフォーマットへと変換します。
例えば、オーディオデータストリームのサンプリングレートの変換や、インタリーブ・デイタリーブ変換といった単純な変換から、圧縮・展開といったより複雑な変換までです。
変換は、以下の3つに分類可能です:

  * (AAC(Advanced Audio Coding)といった)オーディオ形式のリニア PCM 形式へのデコード。
  * リニア PCM データの違うオーディオ形式へのエンコード。
  * 様々なリニア PCM 形式間での変換(例えば、16ビット整数リニア PCM から 32ビット浮動小数点リニア PCM への変換)

Audio Converter API はAudio Converter の作成と操作を可能にします。
多くのビルトインコンバータと共にこの API を使うことで、一般的なオーディオ形式の殆どを扱うことができます。
一時に1つ以上のコンバータを生成することができ、そして変換関数を呼び出した時に使用するコンバータを、指定することができます。
各々の Audio Converter は、コンバータの特性を記述する、プロパティを持ちます。
例えば、チャンネルマッピングプロパティは、どの入力チャンネルを出力チャンネルにマッピングするか、を指定します。

特定のコンバータインスタンスの変換関数を呼ぶことで、入力データの場所と出力データの場所を指定しつつ、データの変換を行うことが出来ます。
殆どの変換作業では、コンバータへ定期的に入力データを送るために、コールバック関数を世窮します。

Audio Codec は特定のオーディオ形式にエンコード、またはデコードする為に Audio Converter が読み込む、Component Manager のコンポーネントです。
一般的に、コーデックはリニア PCM を対象に、エンコード・デコードを行います。
Audio Codec API は Audio Codec を実装するための Componet Manager のインターフェースを提供します。
カスタムコーデックを作れば、Audio Converter を使ってコーデックにアクセスすることができます。
[[audio:core_audio_概要:サポートするオーディオファイルとデータ形式]] は、圧縮形式-リニア PCM 間の変換を行うための、Core Audio 標準のコーデックリストです。

Audio Converter の使用例は、Core Audio SDK の中の、SimpleSDK/ConverterFile と AFConverter コマンドラインツール をご覧ください。

==== ファイル形式情報 ====

Audio File サービスと Audio Converter サービスは、読み込み/書き込み/変換に加えて、ファイルが持つファイルタイプとオーディオデータについての、有益な情報を取得することができます。
例えば、Audio File API を使うと、以下のようなデータを得ることが出来ます:

  * Core Audio が読み書きできるファイルタイプ。
  * Audio File API が読み書きできるデータ形式。
  * ファイルタイプに与えられた名称。
  * ファイルタイプに与えられた拡張子。

Audio File API は、ファイルに関連付けられたプロパティの読み書きもできます。
ファイルに格納されているデータ形式や、CFDictionary が持つジャンル、アーティスト、著作権情報といったメタデータが、プロパティの例です。

==== オーディオメタデータ ====

オーディオデータを扱っているとき、そのデータの最適な処理方法を知るために、具体的な情報が欲しいことがしばしばあります。
この場合、(AudioFormat.h の中の)Audio Format API を使うことで、様々なオーディオ構造体に格納されている情報を照会することができます。
以下は、いくつかの照会可能な特性の例です:

  * 特定のチャンネルレイアウト(チャンネル数、チャンネル名、入出力マッピング)の情報。
  * チャンネルレイアウト間のマッピングで使用できる、パン座標情報。
  * サンプリングレートやビットレート、他の基本的な情報。

これら情報に加えて、Audio Format API が持つ、現在利用可能な Audio Codec 情報といった Core Audio システムに関する詳細な情報も、利用することができます。

==== Core Audio ファイル形式 ====

Core Audio のプログラミングインターフェースの範囲外の技術情報ですが、Core Audio ファイル形式(CAF)は、Apple によって定義された、オーディオデータ格納の為のパワフルで柔軟なファイル形式です。
CAF ファイルには、(AIFF, AIFF-C, WAVE ファイルにあるような)ファイルサイズ制限が無く、そして、チャンネル情報やテキストによる注釈などといった、幅広いメタデータを扱うことが出来ます。
CAF 形式はどんなオーディオデータ形式−まだ存在していないフォーマットでさえも含める程に、充分な柔軟性があります。
Core Audio ファイル形式についての詳細な情報は //[[http://developer.apple.com/documentation/MusicAudio/Reference/CAFSpec/index.html#//apple_ref/doc/uid/TP40001862|Apple Core Audio Format Specification 1.0]]// をご覧ください。

===== ハードウェア抽象化層(HAL)サービス =====

Core Audio は、アプリケーションがハードウェアを扱う際に、一貫性が有り予想可能なインターフェースを提供するために、ハードウェア抽象化層(HAL)を使用します。
各々のハードウェアは、HAL でオーディオデバイスオブジェクト(AudioDevice 型)として表わされます。
アプリケーションはオーディオデバイスオブジェクトに対して、それが持つタイミング情報を照会することができ、同期やレイテンシ調整の為に使用することができます。

HAL サービスは、関数、データ型、定数からなり、これらは CoreAudio.framework に含まれる以下のヘッダファイル中で定義されています:

  * AudioDriverPlugin.h
  * AudioHardware.h
  * AudioHardwarePlugin.h
  * CoreAudioTypes.h (全ての Core Audio インターフェースで利用される、データ型と定数を含みます)
  * HostTime.h

殆どの場合、Apple の AUHAL ユニットがハードウェアインターフェースの要求に応じます。なので、HAL サービスと直接やり取りする必要はありません・
AUHAL は、どんなチャンネルマッピングの要求でも、オーディオデータを固有のオーディオデバイスオブジェクトへと転送する責任を負います。
AUHAL と 出力ユニットの使用についての更なる情報は [[audio:core_audio_概要:interfacing_with_hardware_devices]] をご覧ください。

===== Music Player API =====

Music Player API は、音楽トラックの集合の配置と演奏を可能にします。
この API は関数、データ型、定数からなり、AudioToolbox.framework に含まれる MusicPlayer.h 中で定義されています。

1つの特定のMIDIデータストリーム、またはイベントデータストリームは**トラック**になります(MusicTrack 型)。
トラックは時間ベースのイベントの羅列で、それは MIDI データや、Core Audio イベントデータ、あるいは独自のイベントメッセージであったりします。
トラックが集まると、**シーケンス**になります(MusicSequence 型)。
1つのシーケンスは、必ず付加的なテンポトラックを持ち、それはシーケンス中の全トラックの演奏の同期に使用されます。
アプリケーションは、シーケンス中のトラックの編集、削除、追加を動的に行うことが出来ます。
各々のシーケンスは、対応する Music Player オブジェクト(MusicPlayer 型)に割り当てられていなければならず、そのオブジェクトがシーケンス中の全トラックのコントローラ役を、一手に担います。

トラックは、どの音階をどれくらいの長さで演奏するかを示す、1つの楽器のパート譜に似ています。
シーケンスは、複数の楽器の音符を含む、スコアに当たります。
音源ユニットや外部 MIDI デバイスは楽器として表わされ、一方で Music Player は全ての奏者を束ねる、指揮者に見立てることが出来ます。

Music Player によって処理されたトラックデータは、オーディオ処理グラフや外部 MIDI デバイス、あるいはこれら2つの組み合わせへと送られます。
オーディオ処理グラフは、1つないしそれ以上の音源ユニットを通して、トラックデータを受信します。そして、そのイベント(または MIDI)データを実際のオーディオ信号へと変換します。
Music Player は自動的に、グラフの出力 Audio Unit や Core MIDI と通信し、オーディオ出力の同期を適切にとります。

トラックデータが音楽の情報を表わす必要はありません。
例えば、特別な Core Audio イベントは、Audio Unit のパラメータ値の変化として表わされます。
定位 Audio Unit に割り当てられたトラックは、パラメータイベントを送り、時間とともに音場の中での音源の位置を変更します。
またトラックは、アプリケーションが定義するコールバックにより引き起こされる、独自のユーザーイベントも持つことができます。

Music Player API を使った MIDI データの演奏についての、更なる情報は [[audio:core_audio_概要:midi_データを扱う]] をご覧ください。

===== Core MIDI サービスと MIDI Server サービス =====

Core Audio の MIDI サポートは Core MIDI サービス担います。
このサービスは、関数、データ型、定数からなり、これらは CoreMIDI.framework に含まれる以下のヘッダファイルで定義されています:

  * MIDIServices.h
  * MIDISetup.h
  * MIDIThruConnection.h
  * MIDIDriver.h

Core MIDI サービスは、アプリケーションや Audio Unit が MIDI デバイスとやり取りする為のインターフェースを定義します。
インターフェースは多数の抽象要素で構成されており、アプリケーションが MIDI ネットワークと通信できるようになっています。

**MIDI エンドポイント**(不透明型の MIDIEndpoingRef によって定義されます)は、1つの標準的な16チャンネルの MIDI データストリームの発生源、または行き先にあたります。そして、これは Core Audio サービスとやり取りするための重要なパイプになります。
例えば、エンドポイントと Music Player API が使用しているトラックを関連付けると、MIDI データの再生や記録ができるようになります。
1つの MIDI エンドポイントは、1本の標準 MIDI ケーブル接続を論理的に表わしています。
必ずしも、MIDI エンドポイントが物理デバイスと対応している必要はありません。しかし、アプリケーションは、MIDI データの送受信のために、自分自身を仮想的な発生源または行き先として、エンドポイントに設定することもあります。

MIDI ドライバは、しばしば複数のエンドポイントを **MIDI エンティティ**(MIDIEntityRef) と呼ばれる、論理的なグループにまとめます。
例えば、MIDI-IN エンドポイントと MIDI-OUT エンドポイントを MIDI エンティティとしてまとめることは理にかなっており、デバイスやアプリケーションとの相互直接交信を容易にします。

各々の(単独の MIDI 接続ではない)物理 MIDI デバイスは、Core MIDI デバイスオブジェクト(MIDIDeviceRef)として表わされます。
各デバイスオブジェクトは、1つないしそれ以上の MIDI エンティティを持ちます。

Core MIDI は MIDI Server とやり取りを行い、アプリケーションとデバイス間の実際の MIDI データの送受信を行います。
MIDI Server は、それ自身のプロセスの中で実行され、他のどんなアプリケーションからも独立しています。
Figure 4-2 は Core MIDI と MIDI Server の関係を表わしたものです。

**Figure 2-4** Core MIDI と Core MIDI Server\\
{{core_midi_core_server.jpg|Core MIDI と Core MIDI Server}}

アプリケーションが取り立てて意識する必要のない(application-agnostic)MIDI 入出力のベースに加え、MIDI Server は MIDI THRU 接続も扱うことができます。これは、ホストアプリケーションを介することなく、デバイスとデバイスの接続を可能にします。

MIDI デバイス製造者であれば、カーネルレベル I/O Kit ドライバとやり取りするために、MIDI Server 用に CFBundle でパッケージ化された CFPlugin 形式のプラグインを提供しなければならないかもしれません。
Figure 2-5 は、Core MIDI と Core MIDI Server が、下層にあるハードウェアと、どのようにやり取りするかを示しています。


  メモ:USB MIDI クラスに準拠するデバイスを作成した場合、製造者はわざわざドライバを書く必要はありません。
  なぜならば、Apple の提供する USB ドライバが、そのハードウェアに対応するであろうからです。

**Figure 2-5** MIDI Server が I/O Kit とやり取りを行う\\
{{midi_io.jpg|}}

各々の MIDI デバイスに対するドライバは、通常、カーネルの外側に存在し、MIDI Server プロセスの中で実行されています。
これらドライバは、下層のプロトコル(USB や FireWire など)にそれぞれに対応する、デフォルトの I/O Kit ドライバとやり取りします。
MIDI ドライバには、デバイスの RAW データを、使用に適したフォーマットで Core MIDI に送る責任があります。
そして、Core MIDI はアプリケーションに、指定された MIDI エンドポイントを通して、MIDI 情報を渡します。この時の MIDI エンドポイントは、外部デバイスの MIDI ポート を抽象化したものです。

一方で、PCI カード上の MIDI デバイスは、ユーザー空間のドライバだけでは完全に制御されません。
PCI カードにおいては、カーネルエクステンションを作成し、独自ユーザークライアントを提供しなければなりません。
このクライアントは、その PCI デバイス自体を制御する(ユーザー空間ドライバのために簡単なメッセージキューを提供する)か、ユーザー空間ドライバの要求があった際に、PCI デバイスのアドレス範囲を MIDI Server のアドレスにマッピングするかしなければなりません。
このようにすることで、ユーザー空間ドライバが PCI デバイスを直接制御することが可能になります。

ユーザー空間 MIDI ドライバの実装例は、Core Audio SDK の MIDI/SampleUSBDriver をご覧ください。

===== Core Audio Clock API =====

Core Audio Clocl API は AudioToolbox.framework の CoreAudioClock.h の中で定義され、アプリケーションやデバイスと同期を取るのに使用できる、基準クロックを提供します。
このクロックは単独で動作するタイミング源であったり、MIDI の拍子やタイムコードといった、外部のトリガで同期されるものであったりします。
クロックの開始・停止は、あなた自身の手で行うこともできますし、あるイベントに反応する形で有効・無効の切り替えが行われるように設定することもできます。

生成されたクロックタイムは、秒、拍、SMPTE 時間、オーディオサンプル時間、小節-拍時間を含む、多くの形式で得ることができます。
bar-beat 時間とは、小節、強拍や弱拍などの記号で簡単にディスプレイに表示するようにする為の、ある様式に基づく時間のことです。
Core Audio Clock API は、ある時間形式を別の形式へ変換し、小節-拍時間や SMPTE 時間で表示する、実用的な機能も持っています。
Figure 2-6 は、様々な Core Audio Clock 形式間の相互関係を示しています。

**Figure 2-6** いくつかの Core Audio Clock 形式\\
{{core_audio_clock_formats.jpg|いくつかの Core Audio Clock 形式}}

ハードウェア時間は、ホスト時間(システムクロック)か(HAL によって AudioDevice オブジェクトとして表現される)外部オーディオデバイスから得られるオーディオ時間の、どちらか一方の絶対時間の値を表わします。
mach_absolute_time または AbsoluteTime を呼び出すことで、現在のホスト時間を決定します。
オーディオ時間は、サンプル番号によって表わされる、オーディオデバイスの現在時間です。
サンプル番号の変化は、オーディオデバイスのサンプリングレートに依存します。

メディア時間は、オーディオデータの為の共通のタイミング手法です。
この時間の標準形式は秒であり、倍精度浮動小数点値で表現されます。
しかし、秒を音楽的な小節-拍時間に変換した、所謂テンポを使用したり、秒を SMTPE 秒に変換するために SMTPE オフセットを適用する事も出来ます。

メディア時間を実時間と対応させるべきではありません。
例えば、10秒の長さのオーディオファイルは、2倍速にすれば再生には5秒しかかかりません。
Figure 2-6 の中の切り替えスイッチは、("実際の")絶対時間とそのメディアに基づく時間の相互関係を調整できる、ということを示しています。
例えば、小節-拍表記は音楽演奏のリズムやノートオンのタイミングを表わしますが、発音の長さを表わしてはいません。
つまり、再生レート(拍/分とも言います)を知る必要があると言えます。
同様に、SMPTE 時間から実時間への対応付けも、フレームレートや、フレームを取りこぼすか否かといった要因に依存します。

===== OpenAL(Open Audio Library) =====

Core Audio は、オープンソースな OpenAL 規格の Mac OS X 実装を含みます。
OpenAL は、仮想3次元空間内のサウンドの配置や操作に適した、クロスプラットフォームな API です。
例えば、ゲーム中のサウンドエフェクトの配置や移動、また、マルチチャンネルオーディオのサウンド空間の生成などに、OpenAL を使用することができます。
リスナーを取り囲む単純なサウンド配置に加えて、媒体(霧や水など)を通した際の距離効果、ドップラー効果などを追加することもできます。

OpenAL のコーディング仕様と文法は、OpenGL(唯一の制御は音よりもむしろライト)を模して設計されているので、OpenGL プログラマならば多くの概念が似通っている事に気付くでしょう。

Core Audio での OpenAL の使用例は、Core Audio SDK の Services/OpenALExample をご覧ください。
プログラミングインターフェースや API リファレンスを含む、OpenGL ついてのより詳しい情報は、[[http://openal.org|openal.org]] をご覧ください。

===== システムサウンド API =====

システムサウンド API は、アプリケーション内で標準システムサウンドを再生する簡単な方法を提供します。
この API のヘッダファイル SystemSound.h は、Core Audio 関連ヘッダファイルで唯一、Core Audio フレームワーク外に配置されています。
配置場所は CoreServices/OSServices フレームワークです。

システムサウンド API の使用に関するより詳しい情報は、[[http://developer.apple.com/jp/technotes/tn2102.html|Technical Note 2102: The System Sound APIs for Mac OS X v10.2, 10.3, and Later]] をご覧ください。