在 Loki Entertainment Software，我们处理各种不同的软件。从公共领域到 BSD 许可的源代码，到 GPL 和 LGPL 下的自由软件，到合同和 NDA 下的专有代码，再到闭源硬件驱动程序，我们每天都会遇到所有这些。此外，我们也编写各种源代码。我们移植到 Linux 的游戏不是开源的，但我们自己的工作以自由软件的形式提供，例如 Fenris、Setup、SMPEG 或 SDL 等项目的一部分。

反复跨越各方面的界限，并了解自由软件和开源倡导者的担忧，以及发行商和开发者的担忧，我们的优先事项已经改变。尽管开源和自由软件非常重要，但我们尤其有一个项目发展出来，它认识到还有更重要的东西：开放、文档完善的标准。该项目就是 OpenAL，到目前为止，它的历史是对标准有多重要，以及创建标准有多么困难的一次很好的教育。

随着 Heretic2 和 Heavy Gear 2 的 Linux 移植，Loki 遇到了使用空间化声音的引擎，其程度超出了左右声像。 Heretic2 曾一度成为音频硬件制造商的展示平台：特别是 Aureal 的 A3D 和 Creative 的 EAX 都得到了支持。当时的这两家竞争对手都超越了 DirectSound3D 功能集，并遵循非常不同的空间化声音方法。Windows 游戏开发者夹在三个不同的 API 之间（还不包括为 Windows 提供的众多商业音频 SDK），他们通常选择完全忽略这个问题，并且避免实现高级功能（除非他们决定使用其中一个承诺提供便捷抽象的 SDK 产品）。制造商们加紧努力，并在许多情况下指导开发者将 EAX 或 A3D 支持添加到他们的引擎中。空间化 3D 声音成为一个复选框项目，一个列在游戏包装盒上的功能，在一段时间内，Windows 游戏开发者们过得很轻松。

不幸的是，Linux 用户的情况截然不同。SB16 事实标准的驱动程序支持已经稳定，并且 PCI 声卡总的来说在 Linux 下运行良好。然而，ALSA 或 OSS 专有或开源支持最先进的功能和板卡还没有现成可用。

以 Apple 用户为目标的开发者发现自己也处于类似的情况——虽然 Mac OS 上的多媒体 API 可能比 Linux 解决方案更复杂和完整，但它们与 DirectSound 的兼容性甚至更差，并且同样忽略了 EAX 和 A3D 功能。关心可移植性的 Windows 开发者面临着一个充满闪亮承诺的音频功能集，但没有可移植的 API。鉴于两个主要竞争对手的方法截然不同，情况注定会变得更糟——当时微软甚至没有为许多开发者首选的 NT 平台提供 DirectSound3D。

Creative 是音频硬件市场的主导力量，它发现自己受到了 Aureal 的挑战，后者试图将其在高端空间化声音解决方案方面的经验带入 PC 消费市场。Aureal 提出了“波迹追踪”，这是一种通过模拟声音传播和场景的声学特性来生成空间化声音的专有方法——本质上是通过将场景几何图形提交给声音驱动程序。重要的是要理解，与图形相比，音频技术在很大程度上是，并且仍然是，基于软件的。无论是 Miles Sound System 或 QSound 的 QMixer 等 SDK 的可行市场，还是竞争硬件驱动程序的演变，都清楚地表明了这一点。Aureal 的优势在于他们对模拟、早期反射的计算以及为其驱动程序进行大量优化工作的了解。他们的劣势是 PC 消费市场，在这个环境中，廉价扬声器作为事后才考虑的预算解决方案被添加进来。将高端音频处理从实验室和远离个人头部相关传递函数 (HRTF) 移出，放到大多数用户和大多数开发者实际上并没有过多考虑空间化的桌面上，事实证明极其困难，并且正如我们现在所知，最终是致命的。

尽管所有努力的回报都在减少，但 Aureal 还是成功地完成了一件事：唤醒了人们对游戏中更好 3D 音频的兴趣和初步的用户需求。对于早期采用者来说，它成为一个卖点，发行商和开发者最终也纷纷效仿。Creative 有自己的未来音频功能路线图，它通过强调自己扩展的功能集来反击——一个更简单的解决方案，专注于随机混响来模拟后期反射的效果。在某种程度上，早期和后期反射解决方案是互补的，但 API 和实现从根本上是不同的，而 Creative 选择得很好：EAX 更容易且更简单使用，并且尽管缺乏模拟精度，但随机混响被证明是嘈杂的、低端扬声器桌面更有效的音频提示。

两家公司都在考虑 Linux 计划。一方面，Aureal 拥有“波迹追踪”的完整软件实现，最终以“A2D”的名义销售，以支持竞争对手声卡上的 A3D 功能集，这可能是专有甚至开源示例实现的基础。另一方面，Aureal 的代码库是经过大量优化的汇编代码，Linux 移植并非必然。另一方面，Creative 招募了 Linux 程序员来内部开发驱动程序，并寻找在 Linux 下支持 EAX 的方法。这两个 API 都是针对微软的 DirectX 和 COM 编写的，但 Aureal 基于几何图形的 A3D API 也受到了 OpenGL API 的启发。这是 OpenGL 对 OpenAL 开发产生影响的众多例子之一。

游戏开发者登场了。

甚至在 EAX 和 A3D 时代之前，一些游戏开发者就在寻找可移植的声音解决方案。OpenGL-GameDev 邮件列表，其中聚集了比平均水平更多的对可移植代码感兴趣的开发者，在 1998 年衍生出一个专门讨论新的、开放的音频库的列表——暂定名为 OpenAL。提案被撰写和发布，几位开发者花费了大量时间来提出一个好的解决方案。然而，很快就变得明显，在我们之间，“好”是用非常不同的指标来衡量的。一些订阅者主要对音乐和作曲感兴趣，扎根于声音合成背景。另一些人只关心空间化声音，就像 DirectSound3D 时代那样。有些人喜欢 API 中显式、复杂的 OOP 设计，而另一些人则想要不太自以为是的解决方案。尽管付出了这些努力，但除了几个头文件和一份白皮书外，几乎没有写出什么东西，几个月后，该项目失去了焦点并逐渐消失。缺乏共识，也许缺乏合作努力的经验，导致了早期的失败，但在很大程度上，是缺乏精确的目标，以及需要处理的“音频”功能的种类繁多，注定了第一个 OpenAL 努力的失败，而且不止一次，而是两次。1999 年初，复兴发生了，这与 Jonathan Blow 在为 Game Developer Magazine（1999 年 5 月）撰写的 Sound API 和 SDK 综述中简要提到了 OpenAL 相吻合。Terry Sikes（他撰写了 1998 年的白皮书）和我以侧边栏的形式发表了关于 OpenAL 目标的声明。当时，Aureal 正在考虑修订后的、可移植的 A3D API，我们的声明强调与 OpenGL 的互操作性是可移植音频库的理想属性，尤其是在处理几何图形时。Aureal 和 OpenAL 邮件列表都没有在各自的努力中取得重大进展，直到 1999 年底，另一家公司决定参与进来：Loki。

当时 Heretic2 和 Heavy Gear 2 的工作正在开始，虽然我们当时（而且，说实话，现在仍然没有）能够支持 EAX 或 A3D，但很明显需要某种解决方案。我们需要的最低限度是 DirectSound3D 功能集的 Linux 实现：距离衰减和多普勒效应、3D 空间化、音调和定向声音锥。除此之外，显然希望与 Creative 和 Aureal 等 IHV 进行对话，并培养他们对 Linux 驱动程序的初步兴趣。Loki 联系了最初 OpenAL 讨论的贡献者，建立了一个邮件列表，承诺一名开发者，受人尊敬的 Joseph I. Valenzuela，全职负责软件示例实现，我们三个人开始工作。 Heavy Gear 2 的首席程序员 Michael Vance 和我自己（在 Heretic2 上工作）重新审视了最初的 OpenAL 讨论和现有的提案。考虑到过去的失败，做出了一些决定，特别是对类似 OpenGL 的约定和 API 设计的承诺。当然，从任何方面来看，“音频”问题领域都与图形非常不同，但是通过应用类似 GL 的语法，避免了很多讨论。最初，我们期望 API 的很大一部分以显式方式处理几何图形，就像 A3D 那样，但是我们也对 OpenAL 界面的其他部分应用了相同的推理。模仿 GL 只能让我们走这么远：OpenAL 本质上是一个场景图 API，具有许多显式对象。我们在其他方面也偏离了 GL：OpenAL 的入口点更少，令牌更多，这对于在保持 ABI 向后兼容性的同时更改和弃用 API 机制具有优势。我们采用了 AL、ALC、ALU 和 ALUT 库的分离（松散地类比于 GL、GLX/WGL、GLU 和 GLUT），但几乎完全专注于核心 AL API。短期的痛点导致立即解决，而 Heavy Gear 2 正朝着成为第一款与第一个 OpenAL 示例实现一起发布的 Loki 游戏迈进。即使在早期阶段，我们的 OpenAL 维护者也发现自己正在英勇地努力使库与不断变化的规范草案保持同步。

早在 2000 年 3 月在圣何塞举行的游戏开发者大会 (GDC) 之前，Creative 就表达了对 OpenAL 的兴趣。为了补充他们自己的 Linux 驱动程序工作，并且考虑到可移植性和接受度，供应商中立、操作系统无关的 API 对 IHV 来说变得越来越有吸引力。微软没有表现出扩展 DirectSound3D 的兴趣，而发布了 Interactive 3-D Level 1 和 Level 2 指南的交互式音频特别兴趣小组 (IASIG) 认为自己不负责指定 API。Loki 已尽最大努力使实现和规范适合超出我们短期需求的目的，我们对项目的“开放”部分非常认真，但 Creative 和其他公司表达的兴趣是一个改变规则的惊喜。除了帮助我们完成游戏的 Linux 移植功能外，OpenAL 现在还获得了 IHV 的支持，这最终可能会使其成为标准。

Loki 和 Creative 在 GDC 期间宣布了他们的倡议，我们发布了 Michael Vance 撰写的初始规范草案。从那时起，范围和要求发生了很多变化，并且在过去半年中完成了大量额外工作。虽然我们最初的重点完全是 3D 空间化声音，但我们现在必须支持立体声和多声道格式，其中一些格式（如 MP3）是相当专有的。压缩和流媒体被证明是困难的问题。实施了不止一种解决方案，OpenAL 邮件列表上的 Ian Ollman 的建议导致采用了缓冲队列来处理流式音频。我们必须考虑的实际和潜在功能越多，就必须对 API 应用越多的偏执。向后兼容性被破坏了不止一次，不止两次，而是好几次，添加了扩展以保持已发布游戏的弃用功能可用：Soldier of Fortune 紧随 Heavy Gear 2 之后，随后是 SimCity 3000 Unlimited。到目前为止，Unreal Tournament 也使用了 OpenAL，并且即将推出的基于 UT 许可的游戏移植将继承此功能。Cognitoy 的 Mindrover 在 Linux 下使用 OpenAL，他们以及一些其他 Windows 开发者正在等待发布带有硬件支持的 Win32 OpenAL 驱动程序。目前，实际上所有使用 OpenAL 的游戏都在 Linux 下运行，但希望其他平台很快也会跟进。

在 Loki 的我们三人，以及来自 Creative Labs 的 Jean-Marc Jot、Garin Hiebert、Carlo Vogelsang 和其他人之间，OpenAL 规范已进展到 1.0 版本的最终草案——一个相当完整、坚实的基础，涵盖了 DirectSound3D 功能集，同时在许多细节上偏离了它。例如，缓冲区与源严格分离，并在它们之间共享。有些差异相当微妙，例如钳位距离和参考距离之间的区别，或者多普勒计算中使用的参考速度的显式定义。在某些情况下，例如多声道数据的处理，我们仍然努力以对 API 的最小扩展来解决问题。

在某种程度上，现阶段最大的成就与其说是规范草案本身，不如说是我们在过程中学到的东西。虽然我们离完成还很远，但我们已经建立了一个工作流程和一个 RFC、提案、讨论和修订的参考。我们借鉴了一点 IETF 的经验，并从 OpenGL 的扩展和修改方式中借鉴了很多。我们目前依赖的工具链——DocBook DTD 的 SGML 版本，以及相应的 Linux 解析器和格式化工具——带有一些松散的末端，虽然文档变得更加模块化，但布局和渲染仍有许多不足之处。已经为各种功能提出了扩展，但尚未提供实现。我们决定效仿 SGI 在 OpenGL 方面树立的榜样——在多种意义上——保留了早期 OpenAL 努力中消失的最初动力。在某种程度上，选择“OpenAL”这个名称必须理解为对供应商中立、开放解决方案的明确承诺，我认为我们已经信守了承诺。

下一个里程碑将是正式结束 1.0 规范的最终草案，随后发布适用于 Windows、Linux 和其他平台的硬件 OpenAL 驱动程序。为了实现其承诺，OpenAL 将依赖于高效的驱动程序支持，这项任务必须由 Creative 和其他 IHV 来解决。Loki 鼓励 IHV 尝试开源解决方案，但最终决定权在他们手中。这是开放标准的必要副作用——正如每个自由软件项目都有权实现 OpenAL API 一样，公司可以选择实现专有版本。鉴于优化的实现和改进的算法对于音频 SDK 和驱动程序相对重要，因此需要时间来说服人们接受共享基础设施和开源。

除了当前规范之外，我们现在对 OpenAL 1.1 修订版有了更清晰的路线图。IASIG I3DL2 指南定义的功能集（主要基于 Creative 的提交）将作为供应商特定的扩展添加，目标是在 1.1 中实现供应商中立的解决方案。许多功能请求和添加需要审查，因为我们为 OpenAL 1.0 搁置的问题必须解决。鉴于目前的用户数量很少，我们已经收到了一些相当意外且非常令人惊讶的咨询。上下文处理 API ALC 将必须在多个平台上证明自己，然后我们才能自信地期望，与 OpenGL 不同，我们将在上下文/设备级别也有一个可移植的解决方案。API 目前以牺牲令牌为代价来最小化入口点，一旦语义稳定，可能会找到不同的平衡。同时，我们继续移植新游戏，虽然每个游戏对资源和状态管理都有自己不同的想法，但我们发现现有的 API 非常足够。除了麦克风捕获等新的、正交的功能外，所需的大部分工作都与流媒体和额外的编解码器有关。具有讽刺意味的是，API 路线图此时并不旨在处理反射和遮挡几何图形。虽然显式支持大型反射器仍然可能是有意义的，但游戏引擎通常更适合确定障碍物和遮挡，我们对 OpenAL 的目标已转变为允许应用程序编码器表达此类条件的后果。战场已转移到关于将 OpenAL 用于作曲而不是直接空间化、通用化供应商特定功能或抽象专有解决方案的问题。最初被认为超出 AL 范围并最好留给设备配置和驱动程序实现的 HRTF，已经作为可能的补充出现，基于 Sensaura 在该领域的工作。可能也希望支持 Dolby，这在 Aureal 的路线图上。由 SGI 牵头的 Khronos 流媒体多媒体倡议对 OpenAL 的影响尚待澄清——与 OpenGL 一样，未来可能会将互操作性的扩展添加到 OpenAL 中。

除了设计和编码工作之外，OpenAL 的组织也必须发展。目前志愿者之间以及少数公司之间的松散合作，必须建立为一个非营利组织。再次借鉴 OpenGL 的例子，将设立一个架构审查委员会、一个投票流程以及所有其他与纳入开放标准相关的结构。与 OpenGL 不同，示例实现和最终编写的一致性测试套件将是开源的。与 OpenGL 非常相似，商标的使用将仅限于那些通过某种授权的官方方式通过一致性测试的人。

Brian Paul 的 Mesa 例证了这一切的重要性：在我能想到的所有自由软件项目中，没有其他项目能像他那样，在五年多的时间里，他对 OpenGL API 的洁净室实现，促成了我们今天拥有的硬件加速、具备 3D 图形功能的 Linux 机器。正是 Mesa 提供了框架，而 3dfx 的 Linux Glide 提供了驱动程序，这首先将硬件渲染带入了 Linux (Quake) 游戏。如果没有 SGI 对他们的 OpenGL 规范的勤奋工作，以及他们对 Brian Paul 的支持，我们可能不会有 Linux 的 DRI 开源解决方案，也可能不会有专有的 NVidia 驱动程序。如果有什么的话，我们希望 OpenAL 能够达到 OpenGL 为 Linux 和其他非 Windows 平台所取得的成就。对于 Loki 来说，现在最重要的目标是在 Linux 和 Windows 上获得硬件支持：最终，我们希望我们的游戏开发者同行选择开放标准而不是封闭标准。

这一切值得吗？我们确实承担了超出我们预期的事情，但如果我们迄今为止所做的工作有助于建立另一个可移植的 API，那么答案是肯定的。Linux 才刚刚开始面临标准化和认证的问题，就我个人而言，我对 IETF 的尊重已经成倍增加。Linux 标准库 (LSB) 绝对有他们的工作要做，并且需要它能获得的所有支持。除了 LSB 之外，Linux 桌面还需要一个多媒体 API 补充和特别兴趣小组，以便为 ISV 和 IHV 提供一些立足之地——更不用说所有那些努力实现可移植性的自由软件和业余时间项目了。很可能 Linux 黑客和用户都低估了 DirectX 服务集对整个 Windows 以及特别是 Windows 上的游戏的重要性。许多 Linux 开发者也可能仍然低估了桌面的重要性。然而，Linux 只是需要一套全面的可移植多媒体 API 的众多平台之一。如果 OpenAL 成功地为这样一个操作系统无关的“OpenX”定义了另一个构建块，我们将完成比我们最初预期的多得多的事情。

资源