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

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).

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.]

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.