Whither OpenAL?

delYsid asks: "About a year ago, Slashdot had a story about the OpenAL project by Loki and Creative. There was much hype around it. But if you check their website now, the last changelog entry appears to be from December of 1999! Does anyone know of a good (preferable platform independent) library for 3D audio? The only answer I get when I ask professionals in this field is DirectX. I'd love to have my app under Linux instead of having to move to Win again. Any pointer or hints about the current status of OpenAL? Are there any alternatives?" Update: 09/18 15:33 PM GMT by C :Corrected the link which referred to Slashdot's previous story on OpenAL.

I forwarded this question on to Loki, and here's the response from Scott Draeker, president of Loki Games:

As you can imagine, everyone is pretty busy right now, especially as we had some folks out on vacation the last couple of weeks. So I'm sorry about the slow response.

In answer to your question, work on OpenAL continues. Creative has already added EAX and hardware acceleration to the Mac and Windows versions, and are working on adding both to the Linux implementation as well. Work is also continuing on an OS X port as well as other OSes. OpenAL continues to be the sound API which Loki uses in all of its products, and many other companies are either using or evaluating OpenAL for their products as well.

Hope that helps.

So there you have it, straight from the source. Development is progressing, although it's likely to be a bit slow at present. Here's hoping we'll hear more updates on the progress of OpenAL, over the next 6 months. Thanks a bunch for taking the time to answer, Scott!

Comments

Java

[teknopurge]

Java has 3d audio packages. check out http://developer.java.sun.com.

incidently, i just posted a blurb at techienews about sprint using java in its upcomming 3G network. yes, java.

-teknopurge

mailing list is active

[jas79]

check the archives of the maillinglist.[http://www.openal.org/ml/openal/]

it seems te be active

It is still in development

[michaelsimms]

I am not quite sure where you get the idea it isnt in development. The ftp site has a new tarball as of two days ago.

hardware

[Jacek Poplawski]

I think you can't have 3D audio library without advanced sound device drivers. And AFAIR emu10k1 driver supports effects like delay/flanger/gain, but do not support 3D sound. Main problem is - nobody need advanced sound drivers.
Most of people just need to listen mp3 (it's similiar to word processors - most people need only .doc import/export). The only way to fix that is to create more 3D games for Linux.
So download SDL then get some info from OpenGL site and gamedev then start coding! :-)

Re:weed out these guys

[jnik]

Can slashdot not report on these types of projects until they start producing somethings besides vapor

It's not vapour. You can check it out of their CVS today, compile it, install it. It's shipping with their games: Rune for example uses OpenAL. (Although, as an aside, I wish there were an installation option to use the system library for stuff like SDL and OpenAL rather than installing one just for the game).

OSS/3D

[annenk138]

(From the web site)

OSS/3D is a new 3D audio architecture developed by 4Front Technologies. It is 100% cross platform (available for Windows and UNIX/Linux) and has advanced features that often take 3 or 4 separate products to accomplish.

OSS/3D comprises of a set of digital signal processing (DSP) algorithms that do spatialization, 3D surround, fidelity enhancement, virtual bass boost and speaker configuration.

Currently, OSS/3D comes as a plugin for either Winamp on Windows or X MultiMedia System (XMMS) on Linux/Solaris/FreeBSD.

http://www.oss3d.com

alternative media api: OpenML

[mysticbob]

another initiative to create an alternative cross-platform media api is currently underway under the name OpenML. OpenML is a merging of several media apis from SGI and others. the specifications have been released, and whitepapers, specs, and presentations are on the OpenML website.

openal is good, i use it

[HelloKitty]

openal is actively maintained, just monitor their mailing list. bug reports go in reletively quick too.

I've been using openal on win32, linux, and IRIX without trouble. The only caveat is the API varies just a little between platforms.

Kevin
http://www.mp3.com/subatomicglue

Why OpenAL sucks

[Snocone]

The inimitable Ian Ollmann (who brings up Mac implementation issues on the mac-sound-dev list often) has an interesting piece on why OpenAL sucks here. For the link-shy:

http://maccentral.macworld.com/storyforum/forums /2 001/07/02/music/?read=55

The relevant portions read

Two things are holding such people back from making more substantial contributions to OpenAL. First of all it is not entirely clear to me that the API is all that well designed. Modelling it after OpenGL was probably a mistake. In addition, there are certain fundamental assumptions put into the API that assume preemptive multitasking for some things to work well, most notably spooling file play. There was no thought put into using it for anything other than 3D sound effects for games. So, for example if you attempt to write a MOD player using OpenAL to hopefully be able to take advantage of their SoundFont technology and EAX in your MOD player's core and reverb functionalities, you are pretty much out of luck. OpenAL's source queues lack the functionality required for doing proper timing of various effects that you would need in order to pull it off.

The other problem is that the designers of OpenAL dont want to fix these problems, or let 3rd party developers do it for them. I have argued passionately for months for API improvements such as queue completion callbacks, defered object deletion and a more extensible API to make the library more generally useful for applications and operating systems other than 3D games on linux. I have been unable to convince them to make even the smallest changes to the spec. So, really until we can get some more flexibility and input into the API design, it is somewhat unrealistic to expect me or any other third party, including Apple, to be able to do much for OpenAL.

Re:Why OpenAL sucks

[tjwhaynes]

Two things are holding such people back from making more substantial contributions to OpenAL. First of all it is not entirely clear to me that the API is all that well designed. Modelling it after OpenGL was probably a mistake.

Gotta love this statement. Assert - never qualify.

One of the key points of environmental 3D audio is that it is intended to go hand-in-hand with a 3D visualization of a world. Choosing to use a similar set up to OpenGL struck me as being both an intuitive and sensible way to proceed. Creative certainly thought so when they looked at OpenAL hardware support. This does not mean that you have to use OpenAL for 3D worlds only - OpenGL works well for 2D as well - just look at Chromium BSU.

In addition, there are certain fundamental assumptions put into the API that assume preemptive multitasking for some things to work well, most notably spooling file play.

Well if your system doesn't support pre-emptive multitasking, you are going to have to live with interrupt control. Tricky but not impossible, and something that 99% of the developers aren't going to have to worry about.

There was no thought put into using it for anything other than 3D sound effects for games. So, for example if you attempt to write a MOD player using OpenAL to hopefully be able to take advantage of their SoundFont technology and EAX in your MOD player's core and reverb functionalities, you are pretty much out of luck.

Assertion! No facts!

OpenAL's source queues lack the functionality required for doing proper timing of various effects that you would need in order to pull it off.

Timing is critical in any sound API - OpenAL works fine. Maybe the key difference is that OpenAL does not give a mechanism to stream data into a buffer object, choosing instead to allow the programmer to queue buffers for sources. Essentially this means that the applications is free to do funky stuff up front before submitting the buffers or even (re)processing the buffers on the fly during playback. If you need to do funky things like real-time DSP processing then you are going to have to be able to make guarantees that you can process the data fast enough to keep the sound buffers populated. Beyond that, there is nothing stopping you from writing a MOD player using OpenAL.

Cheers,

Toby Haynes

Re:Why OpenAL sucks

[Naysayer]

I am a game programmer, with a fair number of years of experience at this point. And I think the OpenAL API is horrible.

I don't care at all about the preemptive multitasking part -- old versions of MacOS can bite me. But I do care that it is way, *way* harder to use OpenAL than it should be, and the reason why is that the guys who designed the API had a horrible sense of priorities.

Sound is fundamentally different than graphics; the paradigms that work well for outputting 3D graphics are inappropriate for audio. My biggest issue with OpenAL is that they took the OpenGL/Direct3D driver model of "download texture to the video card" and made their audio buffers work that way by necessity. Now, this is a feature that no game programmer will ever use, for various reasons (the most important of which being that it's just not necessary; sound consumes negligible bandwidth on modern computers, so why try to optimize that bandwidth?). But this feature that nobody with a clue will ever use, being at the core of the API, makes everything way more complicated than it should be. (And, consequently, more bug-prone).

People with 3D graphics experience will tell you that the texture downloading step in 3D graphics is the biggest pain in the ass, and that they'd rather have it not be there if they had the choice. (See e.g. Carmack's plan files of a couple of years ago regarding virtual-memory-style textures, the idea being that you keep them on the host CPU and never explicitly download them.) So the idea of thinking that downloadable textures are cool, and wanting to emulate that in a sound API, smacks of inexperience.

I suspect that part of the reason for this API lameness is that a large part of the development is being undertaken / organized by Creative Labs, who have the agenda of pushing many of their useless hardware acceleration features onto the market. When working on OpenAL, they want to support those features, not necessarily make the objectively best API. (I doubt that the engineers at Creative think their hardware buffer stuff is useless... but it is. Anyone with game experience will tell them so.)

[I was on the OpenAL dev mailing list for a while. I tried to make API suggestions but they were basically ignored.]

Re:Why OpenAL sucks

[Redline]

The other problem is that the designers of OpenAL dont want to fix these problems, or let 3rd party developers do it for them.

Huh? Just like with OpenGL, an OpenAL developer can create extensions to the core API, if there is need. If the extensions are generally useful, they often get folded back into the "main" API. A lot of useful functionality for OpenAL is implemented in Loki created extensions, some of which are obsoleted by the 2.0 API.

Re:Why OpenAL sucks

[Performer Guy]

The criticisms of OpenAL seem entirely reasonable to informed readers. OpenGL is an immediate mode API, an audio API and the nature of audio inherently requires a retained mode implementation from the ground up, probably a scene graph like API. The flaws in OpenAL are obvious and serious.

PLIB isn't that good

[HelloKitty]

I tried plib about a year ago, and OH MY GOD, it was BAD!!!

It supported (get ready):
- 3 simultaneous voices
- 8 bit mono (only)
- not even 3D sound

Does anyone know if it has gotten better in the last year? Maybe I just missed why it is "so good"?

subatomic -
http://www.mp3.com/subatomicglue

Re:PLIB isn't that good

[sbaker]

PLIB's sound is definitely it's worst feature -
and even I (as original author of PLIB) would
recommend you use OpenAL or something. However,
(in case people read this comment out of context),
I presume the "OH MY GOD, it was BAD" part only
refers to the audio - which is a very small fraction of what PLIB does.

Also, the 3-sounds-at-once limit has been fixed
for many months.

Yes, but

[Ian Schmidt]

You have to realize the reason he doesn't like the API requiring preemptive multitasking is that the "classic" MacOS doesn't have it. That's not even an issue on Linux, Win32, or MacOS X.

Re:Yes, but

[Pierre Phaneuf]

Avoiding preemptive multitasking in high performance single-processor programming is a good idea, period.

Both Quake III and Quadra use single-threaded, non-preemptive sound output with great success, so why are so many Linux/others game developers so stubborn on the idea of putting the sound in its own thread?

Personally, I blame the original Doom port, which everyone duplicated, even though at the time it had big problems of latency compared to the single-threaded DOS version because of latencies in the scheduling of the sound process.

No, threads don't avoid this problem. Thank you for trying, but sorry.

Re:Yes, but

[dinivin]

Avoiding preemptive multitasking in high performance single-processor programming is a good idea, period.

Why?

Both Quake III [quake3arena.com] and Quadra [sourceforge.net] use single-threaded, non-preemptive sound output with great success, so why are so many Linux/others game developers so stubborn on the idea of putting the sound in its own thread?

Because so Q3A's sound sucks compared to other games (such as Rune and UnrealTournament) which use OpenAL under Linux, perhaps?

Dinivin

Re:Yes, but

[alannon]

Avoiding preemptive multitasking in high performance single-processor programming is a good idea, period.

Why?

Threading is not 'free'. It comes at a cost in context switches that in simple desktop applications is not noticable, but becomes quite noticable once you're doing a game. In addition, it's impossible to have fine control over the scheduling of preemptive threads. In fact, by definition, you don't have control over it, because it's preemptive. I imagine this can cause serious timing issues for something like sound.

Check out FMod

[magic]

website

A lot of game developers use this; not open source, if that is an issue for you, though.

-m

Your information is incorrect.

[tsaotsao]

The pace of openal development for the linux branch during 2001 has slowed, but has not stopped. I think it's natural that some slow down would have occured, because January saw the commit of the 1.0 spec compliant linux implementation. Until the 1.1 spec is well defined there's not much to do but bug fix and write new backends. So the frenetic pace of commits that lead up to January 2001 can't really be maintained.

That being said, there are lots of spots in the linux implementation that could use bug fixing, or optimizing, or whatever. Since leaving Loki I don't think my position as full-time maintainer was ever filled. I've committed fixes for some more serious bugs but in the vacuum left by my departure a lot of good patches have been left by the wayside.

But the API is good, the implementations on the whole good and getting better. Concerns about the viability of using openal can be addressed by looking at the Loki software titles. In the absence of an official maintainer I'm more than happy to fix things as time permits, but this leaves things open to the vagaries of my work and personal schedule. In general, I really think this criticism is unwarranted ( and your observations about cvs commit dates totally incorrect! ).

That explains it

[Chainsaw]

And before any click-happy Java zealots out there think about hiting reply, I am talking about compiled Java versus compiled C, not Java bytecode on a VM.

Compiled Java is actually slower than JITted Java bytecode. Want proof that Java might actually be as fast as C? This article at Ace's Hardware shows off some pretty interesting numbers.

For 2D use OpenGL. For input use Allegro.

[yerricde]

As well as that, are there any decent cross-platform 2D & Input layers that could fit in with OpenGl, OpenML & OpenAL?

For input, you could use SDL's or Allegro's input layer. For 2D, just use the special case of OpenGL graphics where z = 0 (note that this is also how DirectX 8 does DirectDraw, as a special case of Direct3D 8).

It would be interesting to see how those three fit together, as it really could give OSS a set of API's to combat DirectX with effectivly

AllegroGL (OpenGL graphics + Allegro input + Allegro sound) works nicely.

Re:For 2D use OpenGL. For input use Allegro.

[yerricde]

using OpenGL with a Z of 0 would work too, certainly. Maybe it could be over complicated for 2D though

I don't see how OpenGL would be over-complicated. If you worry about performance issues, rest assured that most modern video cards accelerate parallel (2D or isometric) projections as easily as they do perspective projections.

Alegro is a new one of me. How well does its API fit in with OpenGL/AL/ML? Does it fit at all?

The Allegro library has its own 2D graphics, stereo sound, and joy/mouse/key input functions; it also has fixed-point math (essential for developing for 486 or other low-end targets that leave out FPU for cost or power consumption) and basic 2D and 3D matrix and quaternion manipulation. The base Allegro distribution contains no OpenGL support, but George Foot's AllegroGL extension lets you start OpenGL, make all OpenGL calls, and copy between Allegro surfaces and OpenGL surfaces. However, it doesn't fit in with OpenAL etc. yet.

Re:Enough Java

[Fjord]

Because eventually we will move from 32 bit processors to 64 bit processors.

These days, we bang smaller rocks

[leonbrooks]

They're called ``electrons.''

Java NOT always a good "gaming tech"

[UnknownSoldier]

> It is.

Uncorrect. The real answer is "It depends on the game!"

Anytime someone says "X is a silver bullet", I'm critical of what disadvantes they are overlooking.

We tried, and successfully used Java in one of games. It dropped in, in about a week (of course the game logic took months to write.) Having to use 2 IDE's was a pain, but workable, for debugging. (We made the C++ code into a DLL) There were TWO big problems -- the OVERHEAD from calling Java from C/C++ (or vice versa) *completely* bogged down the game. The other issue was the garbage collector - the game froze while it was doing it's thing, which is unacceptable. (We were doing a single player strategy-sim hybrid, that unfortunately got cancelled, due to other issues.)

Will we use Java again? Maybe. But the scripting language used is only one of the issues regarding gaming tech! One must look at the "pros" AND the "cons." The designers were able to get up to speed quickly with it, appreciated the ton of books on Java programming, and it freed it up one of our programmers of having to maintain a in-house properietary language. However, the designers also lacked the many years of formal training and experience that programmers normally have to go thru, of using a "real language" compared to our easy-to-use previous in-house language. These two things (very bad C/C++ integration, & requiring designers to be programmers) will most likely determine whether we use Java in the future.

I'm the graphics programmer, and personally think Java is not the best tech for game scripting. HOWEVER, I do see its advantages and elegance in using it for game scripting and game logic. It's the old trade-off of "slow & flexible (interpreted) OR "fast and hard-coded (compiled)." Java definately has some advantages - and some disadvantes - like all languages.

I'm sure you can search Carmack's old plans for why he didn't use Java - his reasons were different from ours.

Is Java a viable option? Wild Tangent has clearly shown that a Java-based game works. They have some pretty cool tech.

You might want to read the Gamasutra Post Mortem article on "Vampire" -- That's the only other game developer I know that used Java in a commercial game.

> Too bad most game developers seem to think that a game can't be any good if it

How many game developers do you personally know? That's a pretty broad statement with no basis in fact.

> doesn't spew out 3D graphics at a rate of 500 fps or,
> if it is a strategy game, doesn't have at least have a 3D isometric view in true color.

Game developers are well aware of raising the technical requirements so high, that you loose a lot of customers that don't have the "latest and greatest" video card.

They are also quite aware of Graphics != gameplay.

However, if you DON'T have some of the best graphics, your game is criticized as having "dated graphics." Is that an excuse? No, it's what the consumer wants. Pretty graphics are (usually) what catch the gamers attention, but gameplay is what keeps him/her playing.

It's interesting to note that most of the top selling games are all 2D. i.e. Sims, Diablo, RollerCoaster Tycoon.

If you want a good insight to how the games industry really works, read this Derek Smart's rant on Gaming Industry - Where We Are which dicusses what really happens with the marketing.

Also Avault's series on PC Gaming As An Industry

Bringing this long thread. back on topic -- OpenAL is a good thing, and I'm glad it is progressing. I'll be sure to mention it to our engine architect, next time we do a Mac Port. If we do a Linux port, it will definately make things easier for us. It's a REAL shame OpenGL is completely ignored by so many developers -- using one cross platform API is very cool. Now if only consoles supported it better ;-)

Then again, I'm just a game developer, and this is my opinion.

Java3D supprots portable 3D audio

[catseye_95051]

Since you asked, thought it was worth mentioning.