next »

[Mikademus]

Hi guys!

My framework atm uses OGRE 3D for graphics, CEGUI for, well, GUI, and OIS for input. Now I need an audio library for my game to play sounds and music.

My requirements are:
* C/C++
* Open source under a non-viral copyleft licence (that is, LGPL is goob, but not GPL or similar licences)
* Multi-platform for at least Windows/Linux/MacOS (the big three, but the more the merrier...)

Nice bonuses would be:
* Self-contained (or at least relatively few 3rd party dependencies)
* Mature, but active and viable
* Good feature set and efficiency would always be appreciated!

So what do you use, and what would you recommend or avoid?

[nikki]

i'd recommend openAL or BASS, and i think for licences openAl is more what your after.

[Kaelan]

You could try Audiere. Not sure if it works out of the box on mac but it definitely does on Windows and Linux.

[BrianSlipBit]

i'd recommend openAL or BASS, and i think for licences openAl is more what your after.

I'll second BASS.  I recently started looking at it, and it's nice.

[Mikademus]

Thanks for the replies! I really appreciate it! I've checked out the libraries proposed here.

Here are some tentative conclusions:
* OpenAL seems like an extremely solid system. It also seems very low-level and non-abstracted, and has no native audio file parsing capabilities. It looks like using it is quite a bit of manual management.
* BASS looks very nice, the only drawback is that it is actually a commercial licence, and licences are actually rather expensive for shallow pockets
* Audiere, as mentioned, seems not to be supported for Mac/OSX. It is also very infrequently updated (feb 2006, jul 2003).

I have also located a package called PortAudio, which also seems like a relatively low-level system, albeit perhaps slightly easier to work with than AL? It too, however, does not perform its own file IO.

What are your experiences working with these? Do you have any more recommendations or ideas?

[John Nesky]

I am using PortAudio. I love its simplicity, but I don't recommend it if you're not planning on synthesizing your own sounds. Audio is an inherently and surprisingly complex thing, and it helps to use a library that takes care of some of the pitfalls for you.

[Riley Adams]

I've only used Audiere and OpenAL, so I can't say anything about the others but: OpenAL is great (a bit  low level, but it's all pretty easy after getting a feel for it), and Audiere isn't so great (it hasn't been updated since early 2006, and in my experience the Windows version was rather buggy (it caused random crashes after I started using more than a couple sound effects at a time)).

[Average Software]

I'm a big fan of OpenAL, I even wrote a language binding for it.

The advantages to OpenAL are that it's really easy to get running (open device, create context, bind context, and you're done), and comes standard with Mac OS X and many Linux distributions, so you don't need to worry about its presence on target systems.  For Windows they have a nice installer that you can direct your users too.

The companion ALUT library can load many common audio formats, however it isn't present on OS X so you'd have to build it yourself for that platform.  I prefer to use my own ogg vorbis loader instead, but that's an option.

[LemonScented]

I used OpenAL in a project years ago (2002?) because it was pretty much all I had available, and I hated it for being unfinished and poorly-supported. Every PC game project since then I go back and look at it, evaluate it, want it to be ready for what I need for a game project, and I always go looking elsewhere.

I'm using Audiere at the moment. Yes, it's been far too long since the last update, and yes there are bugs you have to find workarounds for (it plays a short burst of static after one-shot sound effects in MP3 format, for instance - you have to convert them to OGG files then it works fine), but it's remarkably straightforward to use, and for the most part does what it says on the tin.

Try them both, pick which one suits you best. As far as I know there's no other serious option to consider (unless DirectSound has magically become cross-platform with an easy way to install it, which I seriously doubt - pity, because much as I usually hate DirectX stuff, DirectSound is actually quite nice).

[westquote]

I used OpenAL in a project years ago (2002?) because it was pretty much all I had available, and I hated it for being unfinished and poorly-supported.

In the interest of helping other people avoid the headaches you've faced, what things have you found to be unfinished or poorly-supported?  Has any headway been made on these things the last time you looked at it?  Thanks,

--Tim A.

[Kaelan]

* Audiere, as mentioned, seems not to be supported for Mac/OSX. It is also very infrequently updated (feb 2006, jul 2003).

Audiere's SF.net page shows multiple commits around 2 months ago by the original maintainer, and the issue tracker shows at least one patch that supposedly provides a working Mac backend. It's not as actively maintained as OpenAL, but I wouldn't call it dead. In the event that the patch up there isn't totally working, it's not all that hard to rig up support since all you need to give it is a way to provide samples to the soundcard - not too difficult to do.


Also, pretty much anything is better than using OpenAL. Creative Labs is singlehandedly responsible for the removal of hardware audio in Vista/Windows 7; OpenAL pretty much only exists so they can keep selling their terrible sound cards.

If you just want a crossplatform interface to the sound card that you can throw samples at, use SDL - whatever you do, don't code to OpenAL.

[Overkill]

I also like Audiere. I'm using it in my game-engine-in-progress right now. It supported pretty much every format I need, and provided reliable xm and it module playback through DUMB. Before that, I was using FMOD Ex, but I decided I wanted something free to use in any kind of project, and something that didn't sound like stabbing ear pain when listening to certain xm modules with effects.

It was even really simple to hook plugins that would read from a custom file wrapper, I just implemented a class that extended their base file type. This meant that adding in a packfile-aware player without having to create temporary files on disk was possible.

I also liked that, if I wanted to, I could actually statically link audiere (although dynamic linking is entirely possible), making there be no need for any extra DLLs with my engine. The actual benefit of this is pretty minimal, but hey, it was doable.

The doxygen documentation was a little opaque at times though, and I found myself occasionally digging through the library source instead of reading the docs. I think that the documentation and website need to be more frequently updated to make more people aware of Audiere. I'm sure that a tutorial on it would go a long way, too. I'd probably be able to help with something like that if I weren't tremendously busy with school.

Anyways, that said, I hear SDL_Mixer can do a decent job too, in a low-level sort of way.

I have no real opinion on OpenAL, but not particularly liking OpenGL's API (but not like I have a choice for THAT one as much), I figured a similar name meant similarly awful ideas of how you should set up audio samples on a machine.

[Mikademus]

Great feedback guys!

Audiere's SF.net page shows multiple commits around 2 months ago by the original maintainer, and the issue tracker shows at least one patch that supposedly provides a working Mac backend. It's not as actively maintained as OpenAL, but I wouldn't call it dead. In the event that the patch up there isn't totally working, it's not all that hard to rig up support since all you need to give it is a way to provide samples to the soundcard - not too difficult to do.

Ah, thanks for the heads up! I imagine a working audio library could float longer without being inflated than some other components. If it still is being updated, as you say, it feels much more worth testing in earnest.

Also, pretty much anything is better than using OpenAL. ... whatever you do, don't code to OpenAL.

I have no real opinion on OpenAL, but not particularly liking OpenGL's API (but not like I have a choice for THAT one as much), I figured a similar name meant similarly awful ideas of how you should set up audio samples on a machine.

That was sort of my initial reaction as well: why would anyone one to shape a library in a similar style to OGL? I'm not being negative to OGL or users of it here, only the API was defined in more... ah... venerable and eldricht days. Few would define an architecture or naming convention like that today.

I also like Audiere. I'm using it in my game-engine-in-progress right now. It supported pretty much every format I need, and provided reliable xm and it module playback through DUMB. It was even really simple to hook plugins that would read from a custom file wrapper, I just implemented a class that extended their base file type. This meant that adding in a packfile-aware player without having to create temporary files on disk was possible. I also liked that, if I wanted to, I could actually statically link audiere (although dynamic linking is entirely possible), making there be no need for any extra DLLs with my engine. The actual benefit of this is pretty minimal, but hey, it was doable.

Those are some good points in favour of Audiere there: decent format support, static linkage, and if you say it is easy to subclass its loaders for file wrapper support then all the better!

[Average Software]

Also, pretty much anything is better than using OpenAL. ... whatever you do, don't code to OpenAL.

I have no real opinion on OpenAL, but not particularly liking OpenGL's API (but not like I have a choice for THAT one as much), I figured a similar name meant similarly awful ideas of how you should set up audio samples on a machine.

That was sort of my initial reaction as well: why would anyone one to shape a library in a similar style to OGL? I'm not being negative to OGL or users of it here, only the API was defined in more... ah... venerable and eldricht days. Few would define an architecture or naming convention like that today.

Just curious, but what is it that everyone seems to think is so wrong with the GL/AL APIs?

[Mikademus]

About OGL, well, if we stay away from the present situation of being designed-by-committee and OGL3 debacle/debate, what I think most people dislike about it's structure is that it is designed for pure C-linkage, which means no classes and no namespaces. This leads to a hungarian-ish naming convention and a verbose and imperative-driven rather than intent-oriented design. Also, the extensions tend to be a hassle, and if I understood correctly, that too is something that Createive took after, right?

Anyway, I compiled together the data from the different suggestions here at my project wiki, if it could be helpful for anyone.

[Average Software]

what I think most people dislike about it's structure is that it is designed for pure C-linkage, which means no classes and no namespaces.

Well, it is a C library, what did you expect?

Compared to the horribleness of some other C libraries (Windows API, I'm looking at you) OpenGL/AL are breaths of fresh air.  Functionality criticisms may be warranted, but as far as design goes, OpenGL/AL are very clean and consistent libraries.

C linkage also provides maximum compatibility with other languages.  If it were in C++ or something else to provide classes and namespaces, it would be very difficult, sometimes impossible, to map those functions to other languages, mostly due to platform dependent name mangling, also due to C++ features simply not mapping to other languages.  C is something that pretty much everyone can talk to.

[Mikademus]

Wasn't saying it is a bad idea, I was trying to answer the question what people dislike about its design. And since GCC is compilable on every conceivable processor today, ANSI C++ is just as portable as ANSI C. However, when OGL was defined this wasn't the case, so I think the "designed in more venerable and eldrich days" point still holds. And seriously, compared with most Win APIs you can make a pile of putrid animal faeces look inviting. 

[Zaphos]

Wasn't saying it is a bad idea, I was trying to answer the question what people dislike about its design. And since GCC is compilable on every conceivable processor today, ANSI C++ is just as portable as ANSI C.

But portability is not the same as compatibility with other languages, is it?  I mean, with C it's still easier to do stuff like this: http://digitalmars.com/d/2.0/htomodule.html
( they discuss difficulties with doing the same for c++ here: http://digitalmars.com/d/2.0/faq.html#cpp_interface )

[Mikademus]

But portability is not the same as compatibility with other languages, is it?  I mean, with C it's still easier to do stuff like this: http://digitalmars.com/d/2.0/htomodule.html
( they discuss difficulties with doing the same for c++ here: http://digitalmars.com/d/2.0/faq.html#cpp_interface )

Good point, and a good read. I think they argue tendentiously against C++ (D seems to me to see itself as in war against C++) but given that they do catch most reasons for why C-linkage is better (as in the "easier to implement" sense) if the purpose is to provide interfaces to other languages than C/C++.

[Martin 2BAM]

I recommend OpenAL.
SFML has a nice encapsulation of OpenAL.

BASS has a paid license for commercial projects.