30 replies to this topic

[remdul]

Can someone tell me if OpenAL still has a future? It doesn't seem to be actively developed anymore. Or so I have the impression. I've always liked the OpenGL API interface, so it was natural to pick up OpenAL for audio. But I have little positive experience with it. On all of the Creative hardware I tested the OpenAL drivers where broken (broken listener orientation, crackling/popping, doppler not working, inconsistent/unpredictable behavior, some wouldn't even install). I think that's rather sad, since Creative is supposed to be the 'driving force behind OpenAL' (or so their press releases state from time to time). Personally I don't put any trust in Creative because of their low quality drivers, lack of tech support and immoral business practices (patent trolling, see ID Software and A3D cases) in the past. The only reason I still use OpenAL is because it does work consistently in software mode and provides the very minimal. But it still lacks basic features like 2d panning. I'm considering dropping AL and moving on to something that is actively developed. I also believe hardware audio isn't any good anymore these days, software audio seems the way to go. Maybe this is because Creative has a virtual monopoly on the audio accelerator market and killed off all competitors? Please, I don't want to start a flame war. I'm just interested in opinions, your view on things. I don't intend to bash Creative either, it just seems to be the sad state of things; their stuff just doesn't work, and they're not improving. [Edited by - remdul on November 19, 2007 11:37:45 AM]

[Mike2343]

I believe it is, we're using it as our primary library for audio. 1.1 was released a bit ago but not too long. Creative is lacking in their drivers overall. Direct Sound is, I could be wrong here though, being discontinued? I want something that is cross platform and OpenAL fits the bill nicely for now.

[Kylotan]

It's great to see someone who totally agrees with me about Creative. Unfortunately though it seems like your choice of sound libraries are somewhat limited - there are some good ones that are not free, and some average ones that are free.

If I was starting a new C++ project now and had to pick a sound library, I'd probably choose between IrrKlang and FMOD.

[remdul]

Yes, IrrKlang seems very promising, but I have yet to try it.

FMOD is very, very good. It is really as good as they say it is. You can literally get it working in less than an hour. The only downside is the license, the only reason I'm not using it.

Just a few days ago this popped up on the nearly deserted OpenAL-dev mailing list:

http://kcat.strangesoft.net/openal.html

"OpenAL Soft" is a software implementation based on the original source from Creative. I hope this will become an actively developed fork.

The only problem is that the spec won't be updated as long as it is in hands of Creative, but one can add extensions. I wouldn't be surprised if extensions covering EAX/EFX will be added eventually as well, if this thing is picked up by the masses.

I would wonder if Creative would patent-troll against a fork.

[PolyVox]

Anyone got any experience with http://audiere.sourceforge.net/ ? Is it any good?

[Cygon]

I have used Audiere and I love it. In my previous project I basically kicked out fmod and completely replaced it with Audiere after it turned out that Audiere got the job done, provided a much nicer API and was free.

Only later did I discover that Audiere's developer had created the library because he didn't like the hacky fmod C API :)

One word of warning, though: Audiere is still lacking in some places. It's not as tightly optimized as fmod and it has very limited support for 3D audio. It was the perfect match for me, but depending on what features you need and on whether you can accept a C API with void pointers, you might want to stay with fmod.

-Markus-

[Kylotan]

Is there actually any Audiere documentation online? I don't just mean a list of namespaces and classes, I mean actual examples of how you use it. That's why I've never bothered with it.

[Little Coding Fox]

The thing that made me stop even thinking of using OpenAL was that its new license, in 1.1, not only is a full plate of b***, since it literally kills any project you may have, but also you dont even get the right to distribute your programs.

Keeping it short, the license said the following:

* You cant distribute binaries of OpenAL
* You must support only Creative cards
* You must contact a distributer from Creative to distribute your program
* You cant modify OpenAL except for the source of the examples included
* You cant even write an engine that supports OpenAL and license it, they wont accept that

At least that's what i read the last time i was there, and its still the same.

Link

Note: The link points to the OpenAL 1.1 SDK, but it wont start the download unless you accept the license.

So you can see why i also dislike Creative, since they're starting to become yet another developer-unfriendly company lately...

Its sad to see the great ones fall like this.

[Martins Mozeiko]

nuno_silva_pt: Isn't that license for OpenAL SDK? I mean all of your points against OpenAL applies to SDK of OpenAL, not redistributable. Redistributable has much more better license which can be read on installer screen of redistributable.

[Kwizatz]

Quote:

Original post by nuno_silva_pt Keeping it short, the license said the following: * You cant distribute binaries of OpenAL * You must support only Creative cards * You must contact a distributer from Creative to distribute your program * You cant modify OpenAL except for the source of the examples included * You cant even write an engine that supports OpenAL and license it, they wont accept that At least that's what i read the last time i was there, and its still the same.

I believe that only applies to the SDK packaged by Creative, if you compile your own from source, none of that applies, I am even uncertain as to whether it is legal for them to impose those restrictions regardless of how much code they actually contributed.

Related Question: why is it supposed to be version 1.1.0 but the source labels it as 0.0.8?

[haegarr]

Creative has released its new SDK (for windows) only a few monthes ago; see developer.creative.com for it. It supports the OpenAL 1.1 environmental extensions for occlusion and such. Apple has extended its release of OpenAL w/ Leopard as well. Linux support ... well, the latest SI for linux available from www.openal.org is fairly old and always crashed in my trials to open any specific device, and it lacks e.g. device enumeration. The implementation available from the link provided by remdul works well so far, but isn't complete w.r.t. OpenAL 1.1 yet. However, the author seems currently very active to complete it.

So OpenAL seems me not dead yet, I would say it _is_ under active (although slow?) development. But of course its future depends on its attraction of games/engines, and that is a totally other point. The most standpoints in this thread make clear that OpenAL isn't that popular...

[haegarr]

Quote:

Original post by Kwizatz why is it supposed to be version 1.1.0 but the source labels it as 0.0.8?

1.1 is the version of the current OpenAL specification, and 0.0.8 is AFAIK the version of their (SI?) implementation.

[Little Coding Fox]

bubu LV: So, if the SDK is licensed and the redistributable version is not, does that not mean that you must not be a developer in order to use OpenAL? Because i'm talking from the developer point of view, which obviously applies to the OpenAL SDK only.

Kwizatz: 0.0.8 was the last GPL-styled licensed version, new versions seem to be under direct Creative License, it seems. Also, i was talking about the win32 SDK for OpenAL.

Quoting OpenAL.org download page, svn section:

"There are various tagged and branched versions of OpenAL available in openal/tags and openal/branches. These are some of the most relevant:

* Linux_Spec1-0 for the last Linux code before the transition towards OpenAL 1.1 began
* MacOSX1-1_Spec1-0 for the last MacOS X code before the transition towards OpenAL 1.1 began
* Win1-1-2_Spec1-0 for the last Windows code before the transition towards OpenAL 1.1 began"

Doesnt that seem like they want us to download only the code before 1.1? That's why i think 1.1 and such is no longer "valid" as open-source, according to Creative, at least.

[Kwizatz]

Quote:

Original post by nuno_silva_pt Kwizatz: 0.0.8 was the last GPL-styled licensed version, new versions seem to be under direct Creative License, it seems. Also, i was talking about the win32 SDK for OpenAL.

I took a look at the SVN, seems like you could compile your own under Windows as well (uses CMake now).

Now, I may be wrong, but you just can't take a LGPL piece of software and decide to release it under a different license unless you own the IP of said piece of software, which in the case of OpenAL should still belong to Loki or whoever Loki appointed as the holder of rights (its not Creative or is it?).

haegarr's explanation makes more sense in that regard, I know libtool's versioning is closely related to the library's API.

I think it would be interesting to finally find out how well the LGPL/GPL stands in court though.

[samuraicrow]

I hope OpenAL isn't dead yet. SFML uses OpenAL internally. At least as long as I'm using a wrapper, the wrapper's author can reimplement the wrapper functions with OpenSL (Open Sound Library) when it comes out. OpenSL is managed by the Khronos group which is the same group that manages OpenGL.

[remdul]

Quote:

I hope OpenAL isn't dead yet. SFML uses OpenAL internally.

Well, lots of high profile developers use OpenAL as well, but that is irrelevant.
What is relevant is that, AFAIK, Creative holds the spec and they are not updating it to the industry's demands.

Quote:

At least as long as I'm using a wrapper, the wrapper's author can reimplement the wrapper functions with OpenSL (Open Sound Library) when it comes out. OpenSL is managed by the Khronos group which is the same group that manages OpenGL.

Does 'OpenSL' exist? I'm aware of 'OpenSL ES', but not of the non-mobile equivalent (zero hits on Google?). If Khronos adopts OpenAL, or really creates an 'OpenSL', that would be awesome.

[phantom]

Quote:

Original post by remdul What is relevant is that, AFAIK, Creative holds the spec and they are not updating it in respect to the demands of the industry.

Out of intrest, what demands are these?

[remdul]

Quote:

Out of intrest, what demands are these?

The EAX/EFX feature set (rooms, occlusion etc). They are available on Creative hardware, but locked out of the OpenAL API with the intention of IP-whoring. Unlike with OpenGL, extensions will not be adopted as native API features.

How about 2d panning? This comes up on the mailing list almost every week.

But admittedly, the biggest issue is that there are few reliable implementations. I'd say the problem with OpenAL is Creative.

[phantom]

So, in short, your problem is that;

- no one else makes an implimentation apart from Creative
- Creative won't give away their IP for EAX
- The above some how stops others from implimenting their own EFX solution
- This is all Creative's fault despite the spec being public and there being source code out there for people to build on (even if it doesn't include Creative's IP)

The 2D thing might well be a valid issue, although I dare say the rational for not including it is that you can do the same with the 3D system in place just on 2 axis instead of 3. (I've not tried yet, maybe when I do I'll moan about it, we'll see).

However, based on my short list above, and despite having their hardware I'm no Creative fan (the hardware is great, the drivers are often lacking, although I've been pleased thus far with the recent 2 Vista drivers), your complaints seem... lacking.

- No one else doing it is hardly Creative's fault.
- Who gives away IP? Generally no one; GPUs, case and point.
- I've not seen anything in the EFX docs saying 'lulz, Creative only, no else use' which would stop anyone implimenting the interface.
- The stuff is out there, it's free, it's hardly Creative's fault that apart from them no one else bothers with implimenting it.

[Kylotan]

I don't think implementing a few API functions is giving away your IP! Creative's intellectual property is in the implementation of the algorithms, not in the presumably trivial interface to activate them.

Personally I wish people would use other sound cards and abandon OpenAL. Giving one company control over both most of the hardware and the supposed 'open' standard for sound means progress is going to stay stagnant. Sound has barely improved since the 90s, because Creative were allowed to kill off their leading competitor and have never needed to innovate since then.