OpenGLを補完するオーディオAPIとして、OpenALの実装について議論が始まったのが１９９８年あたりです。ヘッダーと仕様の作成についていくつか滞っているものがありましたが、１９９９年の暮れ、Loki Entertainment SoftwareはまさにこのようなAPIを必要とし、仕様定義とLinuxにおける実装に従事しました。
おおよそそのとき、LokiはCreative Labsと、APIの標準化とサポートプラットフォームの拡大について話し始めました。OpenAL 1.0の仕様は２０００年初頭にリリースされ、同年、それに準拠したOpenALライブラリがLinux、MacOS 8/9、WindowsおよびBeOS用にリリースされました。
Loki Entertainmentはまた、２０００年にOpenALを用いたゲームをいくつか出荷しました。— Heavy Gear 2 や Heretic 2 (ともにLinux) —。２００１年にはCreative Labsが初のハードウェアアクセラレーション対応のOpenALライブラリをリリースしました。このライブラリはMacOS 8/9およびWindows上でSoundBlaster Liveをサポートしていました。
２００１年から継続的にOpenALの改良が行われ続けています。いくつかのプラットフォーム（具体的にはBeOSとMacOS 8/9）は２０００年から比べて関連が希薄になっていますが、かわりに多くのプラットフォームが追加されてきました（BSD、Solaris、IRIX、Mac OS Xおよび有名なゲーム機など。）Windows上ではハードウェアサポートが、多くのCreativeとNVIDIAのオーディオデバイスにおいて有効になっています。
製品のサポートについて、OpenALは幾年にわたり膨大な数のタイトル、多くのプラットフォームで使用されました。それらタイトルの数々についてのリストはhttp://www.openal.org/titles.htmlを参照してください。
OpenAL（Open Audio Libraryの略）はオーディオハードウェアに対する、ソフトウェア上のインタフェースです。これにはプログラマが、高品質なオーディオ出力を生成する上でオブジェクトや操作を記述したり、リスナの周囲に三次元的に音源を配置するマルチチャネル出力を記述する為の多くの関数が含まれています。
OpenALのAPIはクロスプラットフォームになるように、また容易に使えるように設計されています。それはOpenGLのAPIと、コーディングスタイルや慣習が似ています。OpenALはOpenGLにおいて当てはまるような構文を使います。
OpenALでは、疑似３次元空間におけるオーディオを生成するのが主要な方法です。その結果、レガシーなオーディオでよくあるような左右チャネルパニングは直接的にはサポートしていません。OpenALは反射・障害物・伝播・反響のような環境効果と同様、（ソースとリスナ間の）距離と方位による減衰やドップラー効果を扱うため、IA-SIG 3Dのレベル１／レベル２レンダリングガイドラインと互換のあるエクステンションを含んでいます。
OpenGLと同様、OpenALのコアAPIは明確なレンダリングコンテキストの概念を持っておらず、暗黙のうちに現在のコンテキストに対し操作します。OpenGLと違いOpenALはコアAPI（事実上のOpenAL API）とOSとのバインディングであるALC API(the Audio Libary Contextの略)の双方が定義されています。ALCはOpenGLにおけるGLXやWGLおよび他のOS依存バインディングと違い、プラットフォーム間で十分に移植可能です。
OpenAL 1.1の実装では６章４節２項や９章１節で定義されているように、録音をサポートしています。
OpenAL 1.1の実装では４章３節２項や９章２節で定義されているように、バイトオフセット単位での操作をサポートしています。
OpenAL 1.1の実装では３章４節３項や９章３節で定義されているように、新たに２つの線形距離モデルをサポートするでしょう。
OpenAL 1.1の実装では３章４節５項や９章４節で定義されているように、新たに２つの指数距離モデルをサポートするでしょう。
３章５節２項で示されている通り、OpenAL 1.1ではドップラー現象が標準化されました。
６章２節１項で示されている通り、コンテキスト生成時に、欲しいモノラル／ステレオのソース数をヒントとして与える事が出来ます。
６章３節３項で示されている通り、OpenAL 1.1ではエクステンションリストの表示が標準化されました。また、alIsExtensionPresentやalcIsExtensionPresentに渡されるエクステンション名は大文字／小文字を区別しません。実装の内部ではそれらの名前は大文字で管理され、また実装中で表現するときも大文字で示されます。
コンテキストのサスペンド／プロセス（訳注：動作を中断したり、そこから再開する機能の事だと思います）については６章２節５項で明示しています。
古いALUTの関数はOpenALライブラリに以前から含まれていたプラットフォームではサポートされ続けるでしょう（Windowsは除く）。
しかし、新たなスタンドアロンなライブラリは別々の設計のもと開発されるでしょうから、新たなライブラリを用いるようお勧めします。
OpenALのキュー機構を用いたストリーミング方法について、４章３節５項で解説しています。
古い仕様ではあいまいだったエラーに対し、多くのケースについてのエラーコードを定義しました。
４章３節２項で示されている通り、OpenAL 1.1でのピッチシフトの限界は変更されました。
新たにALchar型およびALCchar型が追加されました。これらは以下の関数に影響を与えています。
alcCloseDevice関数は処理成功か処理失敗を示す、ALCboolean型を返すようになりました。
AL_VERSION、AL_RENDERERおよびAL_VENDORの文字列クエリについてより明確な定義がなされました。
プログラマにとって，OpenALは三次元空間上にソースやリスナを定義でき、それらソースが出力としてどんな風にレンダリングされるかを操作するコマンドのまとまりです。
実装依存が潜在しており、OpenALコマンドの効果は直接的か否かを保証しませんが、しかし理想的には、そういう潜在はユーザに知り得るべきではありません。
OpenALを用いる典型的なプログラムは、出力を処理し、スピーカやヘッドフォンのようなハードウェアで再生するのに使うサウンドデバイスをオープンすべく、関数呼び出しを始めます。そのとき、ALコンテキストを割り当て、それをデバイスと結びつけます。ひとたびコンテキストが割り当てられれば、プログラマは自由にコマンド発行をすることが出来ます。
他の関数がソースの距離／相対指向性による減衰を含む表現に影響を及ぼす一方、いくつかの関数呼び出しはソースが点音源や指向性音源、ループするか否かを表すのに使います。
実装者にとって、OpenALはCPUおよびサウンドハードウェアの動作に影響を与えるコマンドのまとまりです。もしハードウェアが、アドレスを持つ出力バッファのみで構成されていた場合、OpenALはほぼ完全にホストCPUで実装される必要があります。オーディオハードウェアが異なる範囲においてDSPやその他のアクセラレーションを提供している場合もあります
OpenALの実装者にとって必要な事は、それぞれのALコマンドについてCPUとオーディオハードウェアの間で仕事を分離する間の、CPUソフトウェアのインタフェースを提供する事です。
この仕事の分離は、AL関数呼び出しを行う際最適なパフォーマンスを得られる、有効なオーディオハードウェアのために適応させるべきです。
OpenALはかなりの数のステート情報を保持しています。ステートはどのようにソースを出力バッファにレンダリングするかを制御しています。ステートのいくつかはユーザにとって直接有効になっています。つまりステート値を取得する事が可能です。
しかしながら、それらのいくつかはレンダリング時のエフェクトとしてのみ見えるものです。この仕様書の目的の一つは明確にOpenALステートの情報を作成する事、ステートがどのように変化するかを明らかにする事、その効果は何かを示す事です。
我々はOpenALを、パラメータで決められたディジタル音声信号処理チェインを通ったサンプリングデータ、そのディジタルストリームを合成する多チャンネル処理システムを制御するステートマシンと見なします。
このモデルはプログラマと実装者双方のニーズを満足する仕様を生み出すべきです。しかしながら、それは必ずしも実装にモデルを提供するというわけではありません。
どんな適切な実装も、指定された方法で生成したものに従い結果を生む必要がありますが、特定の、指定されたものよりも効率的な計算を持ち出すという手もあります。
この仕様書は最小値のリソース数を保証します。ただし、実装ではパフォーマンス、有効リソース数、出力品質について切磋琢磨する事を推奨します。
オープンソースのサンプル実装とともに利用可能な、順応性テストがあちます。ベンダや個人はOpenALに対するエクステンションを策定・実装する事を推奨します。成功したエクステンションは必要であり魅力のあるとして、コア仕様の一部になるでしょう。OpenALの実装はマイナー改訂において後方互換性およびABI（訳注：Application Binary Interfaceの略）互換性を保証しなければなりません。
OpenALの現在のサンプル実装および文書はhttp://www.openal.org/から取得する事が出来ます。
OpenGLと同じようにOpenALはARB（Architecture Review Board：アーキテクチャ審議委員会）の定例会における実装者とアプリケーションプログラマの話し合いでの協力を通じて発展させていく事になっています。今現在、ARBはまだ起こっていません。
したがってOpenALは長期間における非公式な協調・努力によるものです。以下のリストは（間違いなく不完全ですが）議論での協力者と仕様策定および関連する努力の貢献者をアルファベット順に示します。
Bob Aron, Juan Carlos Arevalo Baeza, Jonathan Blow, Nathan Charles, Keith Charley, Scott Draeker, Ryan Gordon, John Grantham, Jacob Hawley, Garin Hiebert, Carlos Hasan, Nathan Hill, Stephen Holmes, Bill Huey, Mike Jarosh, Jean-Marc Jot, Maxim Kizub, John Kraft, Bernd Kreimeier, Eric Lengyel, Alexandre Mah, Andrew McDonald, Adam Moss, Ian Ollmann, Rick Overman, Sean L. Palmer, Sven Panne, Daniel Peacock, Pierre Phaneuf, Terry Sikes, Joe Tennies, Jean-Michel Trivi, Joseph Valenzuela, Michael Vance, Carlo Vogelsang