Trying to get SDL_Mixer to work with an existing project

I was using OpenAL, but some idiot thought it’d be funny to make it impossible to manually pan sounds, so I hunted down SDL_Mixer and tried to use it.

It seems it has a single rather deeply rooted dependency on SDL itself:

#define Mix_LoadWAV(file) Mix_LoadWAV_RW(SDL_RWFromFile(file, “rb”), 1)

This _RW stuff is the only way to make the library actually parse what’s in the file properly it seems, wide characters be damned. So I try and include the whole of SDL (MASSIVE overkill for what I want, everything else it does is already handled by other libraries) and it messes with my stdout, piping it to a pair of text files. Why. Why do you people think this is a good idea. Here’s a hint: it’s not. Libraries should simplify functionality, not change arbitrary parts of the language that bear no relation whatsoever to said functionality. So I include the .c file instead of the library as often advised and although I’ve made no changes to it, it says it found an undefined reference to SDL_Main, but provides only an offset in the main.o object file so I don’t know what’s actually going on.

So:

Can I use sdl_mixer’s full functionality without including a huge library for no real benefit?

If not, can I at least stop this redirection madness? You want this functionality? Fine. It’s stupid in that you can’t see messages as the program’s running, it probably isn’t any good for devices with flash storage to be opening and closing two files for no reason, but fine. I don’t, and requiring a total recompile to remove it is absurd.

AAAAAAAAARGH! (16 hours now trying to find a library that a) works b) lets me adjust the left and right volume of a sound manually c) has a license that doesn’t require me to make source available)

Well, I don’t think how your addressing issues you have with SDL is overly
necessarily, still, point taken. I believe to do what you want to do,
you’ll need to compile SDL and SDL_mixer (and distribute, too, if you don’t
want to use the static option)

This is how I’d do it (in unix or mingw32/msys):

cd /path/to/SDL

./configure --disable-video --disable-renderer --disable-events

–disable-joystick --disable-haptic

make

make install

cd /path/to/SDL_mixer

./configure

make

make install

There doesn’t seem to be a way, at least in the configure scripts, to stop
the stdout/stderr redirection, but it honestly wouldn’t be trivial for you
to work around this using C’s file io.

SDL’s RWops system is fairly transparent in the front-end API for SDL_Mixer,
and there is no apparent difference between using Mix_LoadWAV_RW() and
Mix_LoadWAV(), but if there is, file a bug report.

And I’d suggest not to out-right bash SDL’s way of doing things. Sam and
many others have poured in countless hours of developing this library, and
it’s very rude to tell people how their software should work. But that’s
just my two cents.

Let me know if that helps, or if you need further assistence,
-AlexOn Wed, Jun 22, 2011 at 1:11 PM, nexekho wrote:

**
I was using OpenAL, but some idiot thought it’d be funny to make it
impossible to manually pan sounds, so I hunted down SDL_Mixer and tried to
use it.

It seems it has a single rather deeply rooted dependency on SDL itself:

#define Mix_LoadWAV(file) Mix_LoadWAV_RW(SDL_RWFromFile(file, “rb”), 1)

This _RW stuff is the only way to make the library actually parse what’s in
the file properly it seems, wide characters be damned. So I try and include
the whole of SDL (MASSIVE overkill for what I want, everything else it does
is already handled by other libraries) and it messes with my stdout, piping
it to a pair of text files. Why. Why do you people think this is a good
idea. Here’s a hint: it’s not. Libraries should simplify functionality, not
change arbitrary parts of the language that bear no relation whatsoever to
said functionality. So I include the .c file instead of the library as often
advised and although I’ve made no changes to it, it says it found an
undefined reference to SDL_Main, but provides only an offset in the main.o
object file so I don’t know what’s actually going on.

So:

Can I use sdl_mixer’s full functionality without including a huge library
for no real benefit?

If not, can I at least stop this redirection madness? You want this
functionality? Fine. It’s stupid in that you can’t see messages as the
program’s running, it probably isn’t any good for devices with flash storage
to be opening and closing two files for no reason, but fine. I don’t, and
requiring a total recompile to remove it is absurd.

AAAAAAAAARGH! (16 hours now trying to find a library that a) works b) lets
me adjust the left and right volume of a sound manually c) has a license
that doesn’t require me to make source available)


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

I was using OpenAL, but some idiot thought it’d be funny to make it
impossible to manually pan sounds, so I hunted down SDL_Mixer and tried
to use it.

If you want to change each channel in a single AL source, you’d probably
have to use OpenAL’s buffer queueing mechanism and attenuate each sample
yourself before feeding it to the AL, but if that’s all you need OpenAL
for, it’s probably not the right API for you.

This _RW stuff is the only way to make the library actually parse what’s
in the file properly it seems, wide characters be damned. So I try and
include the whole of SDL (MASSIVE overkill for what I want, everything
else it does is already handled by other libraries) and it messes with
my stdout, piping it to a pair of text files. Why.

The RW stuff expects UTF-8 filenames, so it “just works” with usual lazy
American low-ASCII strings, but can still support “wide” characters.
Passing it UTF-16 or UCS-2 will certainly fail, though.

Why do you people think this is a good idea. Here’s a hint: it’s not.

SDL_putenv(“SDL_STDIO_REDIRECT=0”);

Can I use sdl_mixer’s full functionality without including a huge
library for no real benefit?

No. SDL is there to do more than parse .wav files; it handles the actual
feeding of the audio device (and transparently handles DirectSound and
waveout targets). Also, it’s assumed that people using SDL_mixer are
generally using much more of SDL’s functionality.

If not, can I at least stop this redirection madness? You want this
functionality? Fine. It’s stupid in that you can’t see messages as the
program’s running, it probably isn’t any good for devices with flash
storage to be opening and closing two files for no reason, but fine. I
don’t, and requiring a total recompile to remove it is absurd.

It’s there, on Windows, because WinMain-style programs lose their stdio
output by default, so SDL catches it for debugging purposes.

If you’re writing a console program that has a functioning stdout, you
can disable it.

SDL handles a lot of stuff to make cross-platform development easier
(including supplying WinMain for you, which is why you’re getting your
linker error about SDL_main). It sounds like it’s not a good fit for you.

AAAAAAAAARGH! (16 hours now trying to find a library that a) works b)
lets me adjust the left and right volume of a sound manually c) has a
license that doesn’t require me to make source available)

I’m sure FMOD will happily sell you a license.

–ryan.