[ANN] ALmixer: A SDL_mixer-like library built on top of OpenAL

SDL Development
1

I am announcing the first public release of ALmixer (v. 0.1.0)

ALmixer (which I sometimes call “SDL-OpenAL-Mixer” or “SDL_ALmixer”)
is a cross-platform audio library built on top of OpenAL to make
playing and managing sounds easier.

ALmixer provides a simple API inspired by SDL_mixer to make playing
sounds easy with having to worry about directly dealing with OpenAL
sources, buffers, and buffer queuing directly.

ALmixer currently utilizes SDL_sound behind the scenes to decode
various audio formats such as WAV, MP3, AAC, MP4, OGG, etc. (You might
see the connection of why I released a Core Audio backend for
SDL_sound the other day.)

This library is targeted towards two major groups:

  • People who just want an easy, high performance, way to play audio
    (don’t care if its OpenAL or not)

  • People who want to an easy way to play audio in OpenAL but still
    want access to OpenAL directly for effects.

ALmixer is under the LGPL license.

I have setup a website containing more information, Doxygen
documentation, and a link to the Mercurial repository. Go here to
learn more:
http://playcontrol.net/opensource/ALmixer

Thanks,
Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

2

Nice!

Does it follow a similar API? If so, do you have a list of API differences
somewhere?

cheers,On Thu, Oct 28, 2010 at 11:19 AM, Eric Wing wrote:

I am announcing the first public release of ALmixer (v. 0.1.0)

ALmixer (which I sometimes call “SDL-OpenAL-Mixer” or “SDL_ALmixer”)
is a cross-platform audio library built on top of OpenAL to make
playing and managing sounds easier.

ALmixer provides a simple API inspired by SDL_mixer to make playing
sounds easy with having to worry about directly dealing with OpenAL
sources, buffers, and buffer queuing directly.

ALmixer currently utilizes SDL_sound behind the scenes to decode
various audio formats such as WAV, MP3, AAC, MP4, OGG, etc. (You might
see the connection of why I released a Core Audio backend for
SDL_sound the other day.)

This library is targeted towards two major groups:

  • People who just want an easy, high performance, way to play audio
    (don’t care if its OpenAL or not)

  • People who want to an easy way to play audio in OpenAL but still
    want access to OpenAL directly for effects.

ALmixer is under the LGPL license.

I have setup a website containing more information, Doxygen
documentation, and a link to the Mercurial repository. Go here to
learn more:
http://playcontrol.net/opensource/ALmixer

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

3

http://playcontrol.net/opensource/ALmixer/doxygen/
http://playcontrol.net/opensource/ALmixer/almixer-vs-sdl-mixer.htmlOn Thu, Oct 28, 2010 at 8:37 AM, Ren? Dudfield wrote:

Nice!

Does it follow a similar API? If so, do you have a list of API differences
somewhere?

cheers,

On Thu, Oct 28, 2010 at 11:19 AM, Eric Wing wrote:

I am announcing the first public release of ALmixer (v. 0.1.0)

ALmixer (which I sometimes call “SDL-OpenAL-Mixer” or “SDL_ALmixer”)
is a cross-platform audio library built on top of OpenAL to make
playing and managing sounds easier.

ALmixer provides a simple API inspired by SDL_mixer to make playing
sounds easy with having to worry about directly dealing with OpenAL
sources, buffers, and buffer queuing directly.

ALmixer currently utilizes SDL_sound behind the scenes to decode
various audio formats such as WAV, MP3, AAC, MP4, OGG, etc. (You might
see the connection of why I released a Core Audio backend for
SDL_sound the other day.)

This library is targeted towards two major groups:

  • People who just want an easy, high performance, way to play audio
    (don’t care if its OpenAL or not)

  • People who want to an easy way to play audio in OpenAL but still
    want access to OpenAL directly for effects.

ALmixer is under the LGPL license.

I have setup a website containing more information, Doxygen
documentation, and a link to the Mercurial repository. Go here to
learn more:
http://playcontrol.net/opensource/ALmixer

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

Does it support MIDI? At least in the “ALmixer vs. SDL_mixer” page it
doesn’t state whether it can do MIDI, like SDL_mixer does.On 10/28/2010 01:19 PM, Eric Wing wrote:

I am announcing the first public release of ALmixer (v. 0.1.0)

ALmixer (which I sometimes call “SDL-OpenAL-Mixer” or “SDL_ALmixer”)
is a cross-platform audio library built on top of OpenAL to make
playing and managing sounds easier.

ALmixer provides a simple API inspired by SDL_mixer to make playing
sounds easy with having to worry about directly dealing with OpenAL
sources, buffers, and buffer queuing directly.
[…]
http://playcontrol.net/opensource/ALmixer

5

OpenAL supports midi, so I’d assume ALmixer would, too.On Thu, Oct 28, 2010 at 1:34 PM, Nikos Chantziaras wrote:

On 10/28/2010 01:19 PM, Eric Wing wrote:

I am announcing the first public release of ALmixer (v. 0.1.0)

ALmixer (which I sometimes call “SDL-OpenAL-Mixer” or “SDL_ALmixer”)
is a cross-platform audio library built on top of OpenAL to make
playing and managing sounds easier.

ALmixer provides a simple API inspired by SDL_mixer to make playing
sounds easy with having to worry about directly dealing with OpenAL
sources, buffers, and buffer queuing directly.
[…]

http://playcontrol.net/opensource/ALmixer

Does it support MIDI? At least in the “ALmixer vs. SDL_mixer” page it
doesn’t state whether it can do MIDI, like SDL_mixer does.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

Hey Eric,
ALMixer sounds cool. I actually switched from OpenAL to SDL_mixer
about a year ago, but I’m still not dead-set on any one particular
sound engine, so I was wondering if ALMixer addresses any of the
limitations I had with OpenAL. I couldn’t figure out a good way to do
any of these things with OpenAL: Ogg playback, multiple listeners,
scalable amount of stereo pan (good when using headphones or playing
ambient stereo sounds), and non-spatialized sounds (just play a sound
without any processing at all).

Sounds like you have probably already taken care of loading Ogg. The
biggest gripe I had was no multiple listeners, because I have
split-screen multiplayer in my game. The default solution to this
problem was to use OpenAL-soft and set up multiple contexts, but this
seemed like an an awful lot of extra overhead to me. So I switched.–
Terry Welsh
mogumbo ‘at’ gmail.com
www.reallyslick.com

Message: 3
Date: Thu, 28 Oct 2010 03:19:33 -0700
From: Eric Wing
To: sdl at lists.libsdl.org
Subject: [SDL] [ANN] ALmixer: A SDL_mixer-like library built on top of
? ? ? ?OpenAL
Message-ID:
? ? ? ?
Content-Type: text/plain; charset=ISO-8859-1

I am announcing the first public release of ALmixer (v. 0.1.0)

ALmixer (which I sometimes call “SDL-OpenAL-Mixer” or “SDL_ALmixer”)
is a cross-platform audio library built on top of OpenAL to make
playing and managing sounds easier.

ALmixer provides a simple API inspired by SDL_mixer to make playing
sounds easy with having to worry about directly dealing with OpenAL
sources, buffers, and buffer queuing directly.

ALmixer currently utilizes SDL_sound behind the scenes to decode
various audio formats such as WAV, MP3, AAC, MP4, OGG, etc. (You might
see the connection of why I released a Core Audio backend for
SDL_sound the other day.)

This library is targeted towards two major groups:

  • People who just want an easy, high performance, way to play audio
    (don’t care if its OpenAL or not)

  • People who want to an easy way to play audio in OpenAL but still
    want access to OpenAL directly for effects.

ALmixer is under the LGPL license.

I have setup a website containing more information, Doxygen
documentation, and a link to the Mercurial repository. Go here to
learn more:
http://playcontrol.net/opensource/ALmixer

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

7

Does it support MIDI? At least in the “ALmixer vs. SDL_mixer” page it
doesn’t state whether it can do MIDI, like SDL_mixer does.

SDL_sound has an optional Timidity decoder backend. If you compile
SDL_sound with it, then you can get MIDI.

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

8

Actually, OpenAL doesn’t really support MIDI. OpenAL deals with
playing and recording linear PCM data. MIDI is a totally different
animal. However, SDL_sound has a decoder backend (Timidity) that
essentially plays/converts MIDI into linear PCM which effectively lets
you play MIDI through OpenAL.

-EricOn 10/28/10, Alex Barry <alex.barry at gmail.com> wrote:

OpenAL supports midi, so I’d assume ALmixer would, too.

–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

9

I don’t bundle libs, so I’m worried if the distros ship SDL_sound with
MIDI enabled? They do for SDL_mixer.

If not, is it possible to use ALmixer and SDL_mixer in the same app and
at the same time?

Furthermore, does SDL_sound’s MIDI support work in a sane way, or does
it convert the whole MIDI song to WAV first? SDL_mixer plays MIDI directly.On 10/28/2010 09:37 PM, Eric Wing wrote:

Does it support MIDI? At least in the “ALmixer vs. SDL_mixer” page it
doesn’t state whether it can do MIDI, like SDL_mixer does.

SDL_sound has an optional Timidity decoder backend. If you compile
SDL_sound with it, then you can get MIDI.

10

Yes, decoding like Ogg Vorbis is handled through the SDL_sound part of ALmixer.

Multiple listeners I don’t do anything about. ALmixer is mostly
listener agnostic. ALmixer is mostly a wrapper around the OpenAL
buffer and buffer queuing system. It provides a thin wrapper around
OpenAL sources and the listener which is mostly pass through. ALmixer
tries to mostly stay out of the way of 3D effects land so you can
directly tell OpenAL what you want. So I don’t do anything to solve
the multiple listener problem. Multiple contexts is a good way to
think about the problem though. Essentially, a context is a unique
listener.

The other way you could achieve this is keep track of your own
listener states and re-initialize all the listener and source values
every time you need to switch “views”.

As for the overhead involved, I haven’t benchmarked anything. I’m
generally not terribly concerned about overhead of switching some
listener and source values, particularly in a software implementation.
As I mentioned, I originally wrote this thing in 2002 and its now
2010. OpenAL generally gave me much better latency performance than
SDL_mixer in 2002 and computers are much more powerful now (even
mobile devices like iPhone seem to better than what I typically ran in
2002.)

As for stereo pan, again, I defer to OpenAL. It’s up to you to use the
position attributes to simulate stereo pan (not hard). I would imagine
you could implement your own scale factors be manipulating various
OpenAL properties like distance or rolloff factor.

Non-spatialized sounds are kind of the default in OpenAL. You just
don’t set any position coordinates on the sources and listener.
ALmixer doesn’t touch these properties so this is effectively the
default in ALmixer.

-EricOn 10/28/10, Terry Welsh wrote:

Hey Eric,
ALMixer sounds cool. I actually switched from OpenAL to SDL_mixer
about a year ago, but I’m still not dead-set on any one particular
sound engine, so I was wondering if ALMixer addresses any of the
limitations I had with OpenAL. I couldn’t figure out a good way to do
any of these things with OpenAL: Ogg playback, multiple listeners,
scalable amount of stereo pan (good when using headphones or playing
ambient stereo sounds), and non-spatialized sounds (just play a sound
without any processing at all).

Sounds like you have probably already taken care of loading Ogg. The
biggest gripe I had was no multiple listeners, because I have
split-screen multiplayer in my game. The default solution to this
problem was to use OpenAL-soft and set up multiple contexts, but this
seemed like an an awful lot of extra overhead to me. So I switched.

–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

11

Note that SDL_sound has somewhat broken Vorbis support. I decode WAV
and MP3 with SDL_sound, and Vorbis with SDL_mixer to work around the
problem. (Fortunately, it’s possible to use SDL_sound and SDL_mixer at
the same time.)

Here’s a Vorbis file that won’t play correctly with SDL_sound but plays
OK with SDL_mixer:

http://foss.math.aegean.gr/~realnc/files/vorbistest.oggOn 10/28/2010 09:57 PM, Eric Wing wrote:

On 10/28/10, Terry Welsh wrote:

Hey Eric,
ALMixer sounds cool. I actually switched from OpenAL to SDL_mixer
about a year ago, but I’m still not dead-set on any one particular
sound engine, so I was wondering if ALMixer addresses any of the
limitations I had with OpenAL. I couldn’t figure out a good way to do
any of these things with OpenAL: Ogg playback, multiple listeners,
scalable amount of stereo pan (good when using headphones or playing
ambient stereo sounds), and non-spatialized sounds (just play a sound
without any processing at all).

Sounds like you have probably already taken care of loading Ogg. The
biggest gripe I had was no multiple listeners, because I have
split-screen multiplayer in my game. The default solution to this
problem was to use OpenAL-soft and set up multiple contexts, but this
seemed like an an awful lot of extra overhead to me. So I switched.

Yes, decoding like Ogg Vorbis is handled through the SDL_sound part of ALmixer.

12

I don’t bundle libs, so I’m worried if the distros ship SDL_sound with
MIDI enabled? They do for SDL_mixer.

I don’t know. However, if I recall, SDL_mixer also has a Timidity
backend. Timidity is full blown GPL which may cause license issues. So
I am uncertain that all platforms ship SDL_mixer with MIDI support
anyway.

I think last year, Ryan implemented a native Core Audio midi decoder
for SDL_mixer which works around the Timidity problem on OS X. I’m not
sure if the implementation plays through linear PCM or directly plays
through Core Audio’s midi system.

If not, is it possible to use ALmixer and SDL_mixer in the same app and
at the same time?
In general, it’s not supported. There is a conflict with the SMPEG
decoder and the libmikmod decoder so I shut down the SDL audio
subsystem. (Back in 2002, libmikmod doesn’t like having multiple
instances…maybe that’s been fixed.) If you are bold, you might try
running both. Just reactivate the SDL audio subsystem or disable that
line of code in ALmixer that shuts it off.

Furthermore, does SDL_sound’s MIDI support work in a sane way, or does
it convert the whole MIDI song to WAV first? SDL_mixer plays MIDI directly.

SDL_sound converts to PCM (WAV). SDL_mixer actually doesn’t
necessarily play MIDI directly as you state. Technically, I don’t
think SDL itself plays MIDI directly and only does PCM. So if
SDL_mixer is playing through SDL audio, then it is also converting to
PCM. If SDL_mixer is bypassing SDL and doing something special (like
possibly with the Core Audio backend), then it might be doing native
MIDI (though ironically, Apple’s MIDI is effectively converting to PCM
because they have a soft-synth via Quicktime). I don’t know what is
used on Windows. I have a strong feeling that Linux uses Timidity if
anything (since MIDI support on Linux has been traditionally very
limited), and thus is always converting to PCM.

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

13

Note that SDL_sound has somewhat broken Vorbis support. I decode WAV
and MP3 with SDL_sound, and Vorbis with SDL_mixer to work around the
problem. (Fortunately, it’s possible to use SDL_sound and SDL_mixer at
the same time.)

Here’s a Vorbis file that won’t play correctly with SDL_sound but plays
OK with SDL_mixer:

http://foss.math.aegean.gr/~realnc/files/vorbistest.ogg

I hadn’t noticed with the Ogg Vorbis files I’ve used. But I’ll take
your word for it. I recommend you report it to Ryan. Since Ryan is the
author of SDL_sound and a main author of SDL_mixer, he probably can
figure out how to fix this in SDL_sound pretty quick.

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

14

I don’t bundle libs, so I’m worried if the distros ship SDL_sound with
MIDI enabled? They do for SDL_mixer.

I don’t know. However, if I recall, SDL_mixer also has a Timidity
backend. Timidity is full blown GPL which may cause license issues. So
I am uncertain that all platforms ship SDL_mixer with MIDI support
anyway.

I just looked up the sources, and only the Linux native MIDI support is
GPL. But it doesn’t work in the first place (it’s OSS, not ALSA; it
worked 10 years ago, not anymore).

I think last year, Ryan implemented a native Core Audio midi decoder
for SDL_mixer which works around the Timidity problem on OS X. I’m not
sure if the implementation plays through linear PCM or directly plays
through Core Audio’s midi system.

It plays though Core Audio on OS X, and MM API on Windows. On Linux,
the notes are played in realtime through the included Timidity.

Furthermore, does SDL_sound’s MIDI support work in a sane way, or does
it convert the whole MIDI song to WAV first? SDL_mixer plays MIDI directly.

SDL_sound converts to PCM (WAV). SDL_mixer actually doesn’t
necessarily play MIDI directly as you state. Technically, I don’t
think SDL itself plays MIDI directly and only does PCM. So if
SDL_mixer is playing through SDL audio, then it is also converting to
PCM. If SDL_mixer is bypassing SDL and doing something special (like
possibly with the Core Audio backend), then it might be doing native
MIDI (though ironically, Apple’s MIDI is effectively converting to PCM
because they have a soft-synth via Quicktime). I don’t know what is
used on Windows. I have a strong feeling that Linux uses Timidity if
anything (since MIDI support on Linux has been traditionally very
limited), and thus is always converting to PCM.

Well, in the end everything is PCM, since modern sound cards don’t have
MIDI wavetables on them. The question was rather whether the whole MIDI
is converted to PCM first, or only in small chunks so you get
immediately audible notes and sane memory consumption.On 10/28/2010 10:13 PM, Eric Wing wrote:

15

I don’t bundle libs, so I’m worried if the distros ship SDL_sound with
MIDI enabled? They do for SDL_mixer.

I don’t know. However, if I recall, SDL_mixer also has a Timidity
backend. Timidity is full blown GPL which may cause license issues. So
I am uncertain that all platforms ship SDL_mixer with MIDI support
anyway.

I just looked up the sources, and only the Linux native MIDI support is
GPL. But it doesn’t work in the first place (it’s OSS, not ALSA; it
worked 10 years ago, not anymore).

I think last year, Ryan implemented a native Core Audio midi decoder
for SDL_mixer which works around the Timidity problem on OS X. I’m not
sure if the implementation plays through linear PCM or directly plays
through Core Audio’s midi system.

It plays though Core Audio on OS X, and MM API on Windows. On Linux,
the notes are played in realtime through the included Timidity.

Back in 2002, and I know that the Core Audio backend in 2010 does not
let you select a target midi device if you have one. (I have a Roland
Sound Canvas…SDL_mixer has never played through it.)

Well, in the end everything is PCM, since modern sound cards don’t have
MIDI wavetables on them. The question was rather whether the whole MIDI
is converted to PCM first, or only in small chunks so you get
immediately audible notes and sane memory consumption.

SDL_sound let’s you decode small chunks or everything. ALmixer follows
that abstraction hence the LoadStream and LoadAll APIs. If you want to
stream, use LoadStream and the right thing should happen.

-EricOn 10/28/10, Nikos Chantziaras wrote:

On 10/28/2010 10:13 PM, Eric Wing wrote:
–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

16

I think the “way to go” with ALmixer would be to scrap SDL_sound
completely and directly use each platform’s multimedia frameworks. It
just seems better to not use implementations that are somewhat
half-assed to begin with. For example, MP3 support in SDL_sound is not
done with something like libmad or other “good” lib, but with either
SMPEG or code from mpg123, and both are outdated and not good at
decoding all kinds of MPEG audio. Vorbis support is also wacky.

But I guess that’s just too much work. In any event, that’s what I was
always searching for for quite some time :stuck_out_tongue: There’s a saying that goes
like “every piece of software has to suck in at least one way, no matter
how good it is otherwise.” Not sure where I read it. In this case, the
situation was like this:

  • SDL_mixer mostly works. But for some reason it only allows one music
    stream, which sucks. You’re forced to load whole MP3/Ogg/WAV files into
    RAM and play them as channels.

  • Phonon mostly works. But lacks MIDI support, which sucks.

  • Allegro mostly works. But MIDI support is mostly useless, which sucks.

  • FMOD works and then some. But it’s not compatible with the license of
    my apps, which sucks.

The list goes on with other sound libraries but I forgot their names;
some looked awesome, but lacked some key feature, like MP3 support
because it’s not “free”, an important platform/OS was not supported, the
license was incompatible, etc.

I still hope for some sound lib to come along that lacks the “sucks in
at least one way” part. When I read your initial ALmixer announcement
in this list, I was kind of hoping this would be it :-POn 10/28/2010 10:19 PM, Eric Wing wrote:

Note that SDL_sound has somewhat broken Vorbis support. I decode WAV
and MP3 with SDL_sound, and Vorbis with SDL_mixer to work around the
problem. (Fortunately, it’s possible to use SDL_sound and SDL_mixer at
the same time.)

Here’s a Vorbis file that won’t play correctly with SDL_sound but plays
OK with SDL_mixer:

http://foss.math.aegean.gr/~realnc/files/vorbistest.ogg

I hadn’t noticed with the Ogg Vorbis files I’ve used. But I’ll take
your word for it. I recommend you report it to Ryan. Since Ryan is the
author of SDL_sound and a main author of SDL_mixer, he probably can
figure out how to fix this in SDL_sound pretty quick.

17

I would make a stronger claim and say all the MIDI support you listed
sucks. If something says it does MIDI, I expect to be able to access
specific MIDI devices, control basic MIDI parameters like channels,
patch changes, bank changes, note velocity, transpose, tempo, etc,
etc. None of these libraries you list come close to touching any of
that. I think a digital audio system like OpenAL is a poor way to do
MIDI.

I think the “way to go” with ALmixer would be to scrap SDL_sound
completely and directly use each platform’s multimedia frameworks. It
just seems better to not use implementations that are somewhat
half-assed to begin with. For example, MP3 support in SDL_sound is not
done with something like libmad or other “good” lib, but with either
SMPEG or code from mpg123, and both are outdated and not good at
decoding all kinds of MPEG audio. Vorbis support is also wacky.

Scrapping SDL_sound might be overkill. SDL_sound was designed so you
could implement new decoders including native platform decoders. That
is exactly what I did with my Core Audio decoder submission. It works
great on iOS and Mac OS X and I get hardware accelerated AAC, MP4, MP3
on iOS. I strongly encourage you to add more native decoders to
SDL_sound.

That said, ALmixer has very few dependencies on SDL itself. (In fact,
I have a private fork that bypasses SDL and SDL_sound for iOS and
utilizes (only) my native Core Audio decoder directly so I can
statically link on iOS without being bound by the LGPL.) So it would
be nice to have a SoundDecoder library that didn’t bring in the SDL
dependencies. But SDL_sound is the only cross-platform stand-alone
decoder that I know of that has attempted to do decoding with a
singular/unified API.

But I guess that’s just too much work.

Yes, it is a ton of work, which is why SDL_sound is probably the best
library around. Again, please contribute new decoder backends to make
it better.

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

18

Hey Eric, great job!
We tried going with openal some time ago with a custom wrapper.
It was fun to use, expecially fro osx and ios, we got it running on
linux, but in the end the whole thing had to stop because on windows
there’s the usual driver mess.
Some drivers worked fine, creative ones cheated claiming they
supported openal but missed many feature, and some others just didn’t
work.
How does ALmixer handle all this? does it have a fallback driver? an
automatic software render?

another question is SDL_sound and or ALmixer going to be a replacement
for SDL_mixer in the next years?

bye
VittorioOn Thu, Oct 28, 2010 at 12:19 PM, Eric Wing wrote:

I am announcing the first public release of ALmixer (v. 0.1.0)

ALmixer (which I sometimes call “SDL-OpenAL-Mixer” or “SDL_ALmixer”)
is a cross-platform audio library built on top of OpenAL to make
playing and managing sounds easier.

ALmixer provides a simple API inspired by SDL_mixer to make playing
sounds easy with having to worry about directly dealing with OpenAL
sources, buffers, and buffer queuing directly.

ALmixer currently utilizes SDL_sound behind the scenes to decode
various audio formats such as WAV, MP3, AAC, MP4, OGG, etc. (You might
see the connection of why I released a Core Audio backend for
SDL_sound the other day.)

This library is targeted towards two major groups:

  • People who just want an easy, high performance, way to play audio
    (don’t care if its OpenAL or not)

  • People who want to an easy way to play audio in OpenAL but still
    want access to OpenAL directly for effects.

ALmixer is under the LGPL license.

I have setup a website containing more information, Doxygen
documentation, and a link to the Mercurial repository. Go here to
learn more:
http://playcontrol.net/opensource/ALmixer

Thanks,
Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

19

Hey Eric, great job!
We tried going with openal some time ago with a custom wrapper.
It was fun to use, expecially fro osx and ios, we got it running on
linux, but in the end the whole thing had to stop because on windows
there’s the usual driver mess.
Some drivers worked fine, creative ones cheated claiming they
supported openal but missed many feature, and some others just didn’t
work.

So on Windows, there are two basic solutions. Use Creative’s drivers
or use OpenAL soft. Early on, Creative had some issues (though all the
implementations had issues). I would hope they are resolved now. I
don’t hear many complaints on the OpenAL mailing list anymore. OpenAL
Soft is your alternative. People who like bundling OpenAL with their
app and avoid installers seem to gravitate towards OpenAL soft.

OpenAL soft is the only game in town on Linux. But the maintainer,
Chris Robinson, is very active on it and it seems like a solid
distribution to me. He is usually the first to propose new extensions
to OpenAL and implement them.

How does ALmixer handle all this? does it have a fallback driver? an
automatic software render?

ALmixer does very little. (It actually has some legacy stuff in the
code base which tries to do too much…you might see esoteric
references to Loki, Creative, and Nvidia which are pretty much
obsolete now.) At one time, I supported a way to pass custom settings
to the Init, so if there was an implementation specific way of setting
things, you could try to do this. Maybe the Creative implementation
still lets you control things? But I kind of dropped this mess after
OpenAL 1.1 was ratified. If you have a specific things you need to do,
I’m willing to listen. My hope is that OpenAL 1.1 is consistent enough
that you won’t need to care any more, at least w.r.t. what ALmixer
needs to do.

another question is SDL_sound and or ALmixer going to be a replacement
for SDL_mixer in the next years?

ALmixer probably won’t replace SDL_mixer from a policy point. However,
if people just start using ALmixer entirely, it could happen
unofficially that way. But there are a lot of milestones that need to
happen before that ever happens. (Testing, better examples, better
documentation, binary releases, etc.) And I don’t think there is any
plan to retire SDL_mixer. (I am not involved in that decision process.
ALmixer is entirely my own crazy invention and is not coordinated with
official SDL in any way.)

A long time ago, it was planned/expected that SDL_mixer’s decoder
backend would be replaced to use SDL_sound. However, that still hasn’t
been done.

-EricOn 10/28/10, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/