The Story of OpenAL

Loki and Creative announced their initiative during GDC, and we published the initial specification draft written by Michael Vance. Since then, the scope and requirements have changed quite a bit, and a lot of additional work was done during the last half-year. While our original focus was solely on 3-D spatialized sound, we now have to support stereo and multichannel formats, some of which (like MP3) are quite proprietary. Compression and streaming proved to be difficult issues. More than one solution was implemented, and it was a suggestion from Ian Ollman on the OpenAL mailing list which led to the adoption of buffer queueing to handle streaming audio. The more actual and potential features we had to account for, the more paranoia had to be applied to the API. Backward compatibility was broken not once, not twice, but several times, with extensions added to keep deprecated features available for the games we had already shipped: Soldier of Fortune followed Heavy Gear 2 and was followed by SimCity 3000 Unlimited. By now, Unreal Tournament uses OpenAL as well, and upcoming ports of games based on the UT license will inherit this feature. Cognitoy's Mindrover uses OpenAL under Linux, and they, as well as a few other Windows developers, await the release of Win32 OpenAL drivers with hardware support. At the moment, practically all games that use OpenAL do so under Linux, but other platforms will hopefully follow soon.

Between three of us at Loki, and Jean-Marc Jot, Garin Hiebert, Carlo Vogelsang and others from Creative Labs, the OpenAL specification has progressed to a final draft of the version 1.0—a reasonably complete, solid foundation that covers the DirectSound3D feature set, at the same time deviating from it in many details. For example, buffers are strictly separate from sources and are shared among them. Some of the differences are rather subtle, like the distinction between clamping and reference distances, or the explicit definition of the reference velocity used in Doppler calculations. In some cases, like the handling of multichannel data, we still strive to get away with a minimal extension to the API.

To a degree, the biggest accomplishment at this stage is not so much the Specification Draft itself, but what we have learned in the process. While we are still far from finished, we have established a work flow and a reference for RFC's, proposals, discussions and revisions. We borrowed a little from the IETF and quite a lot from the way OpenGL is extended and modified. The toolchain we currently rely on—the SGML version of the DocBook DTD, and the respective Linux parser and formatting tools—comes with a couple of loose ends, and while the document has become more modular, the layout and rendering leaves a lot to be desired. Extensions have been proposed for various features, but implementations have not yet been provided. Our decision to follow the example SGI set with OpenGL—in several senses—has preserved the initial momentum that vanished from the earlier OpenAL efforts. In a way, choosing the name “OpenAL” has to be understood as a clear commitment to a vendor-neutral, open solution, and I think we have kept the promise.

The next milestone will be the official closure on the final draft of the 1.0 specification, followed by releases of hardware OpenAL drivers for Windows, Linux and other platforms. To fulfill its promise, OpenAL will depend on efficient driver support, a task that has to be addressed by Creative and other IHVs. Loki encourages IHVs to try open-source solutions, but the ultimate decision is theirs. This is a necessary side effect of an open standard—just as every free software project has the right to implement the OpenAL API, companies can choose to implement proprietary versions. Given the relative importance of optimized implementations and improved algorithms for audio SDKs and drivers, it will take time to make a case for shared infrastructure and open source.

Beyond the current specification, we have now a much clearer roadmap for the OpenAL 1.1 revision. The feature set defined by the IASIG I3DL2 guidelines, which are largely based on submissions by Creative, will be added as a vendor-specific extension, aiming for a vendor neutral solution in 1.1. A lot of feature requests and additions have to be reviewed, as issues we set aside for OpenAL 1.0 have to be resolved. Given the small amount of users at this time, we have already gotten some rather unexpected and quite surprising inquiries. The context handling API, ALC, will have to prove itself on several platforms before we can confidently expect that, unlike OpenGL, we will have a portable solution at the context/device level as well. The API, currently minimizing entry points at the expense of tokens, might find a different balance once the semantics are found stable. Meanwhile, we continue to port new games, and while each one has its own different idea about resource and state management, we find the existing API to be quite sufficient. Aside from new, orthogonal features like microphone capture, the majority of the work required is related to streaming and additional codecs. Ironically, the API road map does not aim for handling reflection and occlusion geometry at this point. While it still might make sense to explicitly support large reflectors, the game engines are usually much better equipped to determine obstruction and occlusion, and our objective for OpenAL has shifted to allow the application coder to express the consequences of such conditions. The battlefield has shifted to questions about use of OpenAL for composition instead of straightforward spatialization, generalization of vendor-specific features or abstraction of proprietary solutions. HRTFs, initially considered to be outside the scope of AL and better left to device configuration and driver implementation, have emerged as a possible addition, based on Sensaura's work in this area. Support for Dolby, which was on Aureal's road map, would probably be desirable as well. The implications of the Khronos Initiative for streaming multimedia, spearheaded by SGI, with respect to OpenAL has to be clarified—like OpenGL, extensions for interoperability might be added to OpenAL in the future.

Beyond the design and coding work, OpenAL's organization will have to evolve. What is currently a loose cooperation between volunteers, with a few companies thrown into the mix, will have to be established as a nonprofit organization. Again borrowing from OpenGL's example, there will be an architecture review board, a voting process and all the other structures that come with incorporating open standards. Unlike OpenGL, the sample implementation and the eventually written conformance test suite will be open source. Much like OpenGL, the use of the trademark will be restricted to those who passed the conformance test in some authorized, official way.

The importance of all this is exemplified by Brian Paul's Mesa: like no other free software project I can think of, his clean room implementation of the OpenGL API has, over more than five years, led to the hardware accelerated, 3-D-graphics-capable Linux machines we have today. It was Mesa that provided the framework, and 3dfx's Linux Glide that provided the driver, which brought hardware rendering to Linux (Quake) gaming in the first place. Without SGI's diligent work on their OpenGL specification, and their support for Brian Paul, we might not have the DRI open-source solutions for Linux and probably would not have the proprietary NVidia drivers either. If anything, we want OpenAL to match what OpenGL accomplished for Linux and other non-Windows platforms. For Loki, the most important goal now is to get hardware support on Linux—and Windows: ultimately, we want our fellow game developers to choose open standards over closed ones.