The Story of OpenAL

Open Source and Open Standards: Chapters One through Three. A voyage through one of Loki's free software projects.
Scratching the Itch

Even before the days of EAX and A3D, some game developers were looking for a portable sound solution. The OpenGL-GameDev mailing list, which hosts more than its average share of developers interested in portable code, spawned in 1998 a list dedicated to discussion of a new, open audio library—tentatively named OpenAL. Proposals were written and posted, and several developers spent significant time coming up with a good solution. However, it quickly became apparent that between us, “good” was measured by very different metrics. Some of the subscribers were mainly interested in music and composition, solidly grounded in a sound synthesis background. Others cared only about spatialized sound, as it was in the days of DirectSound3D. Some preferred explicit, sophisticated OOP design in the API, while others wanted solutions that were less assuming. For all those efforts, little more than a few headers and a white paper were written, and over the months the project lost focus and tapered out. Lack of consensus and maybe a lack of experience in cooperative efforts contributed to this early failure, but to a much larger degree it was the lack of precise objectives, and the sheer variety of “audio” features to deal with, that doomed the first OpenAL effort not once, but twice. In early 1999, a resurrection occurred, coinciding with a brief mention of OpenAL in Jonathan Blow's roundup of Sound API's and SDK's for Game Developer Magazine (May 1999). Published as a sidebar, Terry Sikes (who had written the 1998 white paper) and I stated the objectives of OpenAL. At that time, Aureal was considering a revised, portable A3D API, and our statement emphasized interoperability with OpenGL as a desirable property for a portable audio library, especially if processing geometry. Neither Aureal nor the OpenAL mailing list made significant progress in their separate efforts, and it wasn't until late 1999 that another company decided to get involved: Loki.

Work on Heretic2 and Heavy Gear 2 was commencing at that time, and while we were not (and, truth to be told, still are not) in a position to support EAX or A3D, it became obvious that some solution was needed. The minimum we needed was a Linux implementation of the feature set of DirectSound3D: distance attenuation and Doppler Effect, spatialization in 3-D, pitch and directional sound cones. Beyond that, it would obviously be desirable to talk to IHVs like Creative and Aureal and nurture their tentative interest in Linux drivers. Loki approached contributors to the original OpenAL discussion, set up a mailing list, committed one developer, the esteemed Joseph I. Valenzuela, full-time to the software sample implementation, and the three of us set out to work. Michael Vance, the lead coder on Heavy Gear 2, and myself (working on Heretic2) revisited the original OpenAL discussion and the existing proposals. A number of decisions, in particular the commitment to OpenGL-like conventions and API design, were taken with an eye on the past failures. Of course, the problem domain “audio” is very different from graphics by any account, but a lot of discussions were avoided by applying GL-like syntax wherever applicable. Initially, we expected a good deal of the API to handle geometry in explicit ways, just as A3D did, but we also applied the same reasoning to other parts of the OpenAL interface. Mimicking GL only got us so far: OpenAL is essentially a scene graph API, with a lot of explicit objects. We deviated from GL on other accounts as well: OpenAL has less entry points and more tokens, which has advantages for changing and deprecating API mechanisms while preserving ABI backward compatibility. We adopted a separation into AL, ALC, ALU and ALUT libraries (in loose analogy to GL, GLX/WGL, GLU and GLUT) but almost exclusively focused on the core AL API. Short-term itches led to immediate scratching, and Heavy Gear 2 was heading toward being the first Loki game to ship along with the first OpenAL sample implementation. Even at that early stage, our OpenAL maintainer found himself in valiant struggle to keep the library in sync with the ever-changing specification drafts.

It was well before the Game Developer's Conference (GDC) in March 2000 in San Jose, that Creative expressed interest in OpenAL. To complement their own Linux driver work, and with respect to portability and acceptance, a vendor-neutral, OS agnostic API had become increasingly attractive for IHV's. Microsoft did not exhibit interest in extending DirectSound3D, and the Interactive Audio Special Interest Group (IASIG), which had published Interactive 3-D Level 1 and Level 2 guidelines, did not consider itself in the business of specifying API's. Loki had tried its best to keep the implementation and the specification suitable for purposes beyond our short-term needs, and we were quite serious about the “Open” part of the project, but the interest expressed by Creative and others was a surprise that changed the rules. Beyond helping us in getting Linux ports of games feature complete, OpenAL now had IHV backing that might eventually establish it as a standard.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix