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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState