Whither OpenAL? 103
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!
Java (Score:2, Informative)
incidently, i just posted a blurb at techienews about sprint using java in its upcomming 3G network. yes, java.
-teknopurge
mailing list is active (Score:4, Informative)
it seems te be active
I use it (Score:1, Informative)
It is still in development (Score:4, Informative)
hardware (Score:4, Informative)
Most of people just need to listen mp3 (it's similiar to word processors - most people need only
So download SDL [libsdl.org] then get some info from OpenGL site [opengl.org] and gamedev [gamedev.net] then start coding!
Re:weed out these guys (Score:3, Informative)
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 (Score:2, Informative)
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 [oss3d.com]
Re:Why OpenAL sucks (Score:3, Informative)
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
Your information is incorrect. (Score:2, Informative)
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 (Score:2, Informative)
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 [aceshardware.com] shows off some pretty interesting numbers.
Re:Why OpenAL sucks (Score:3, Informative)
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 (Score:2, Informative)
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 [openal.org], some of which are obsoleted by the 2.0 API.
Re:PLIB isn't that good (Score:2, Informative)
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.