Should SDL_mixer include MP3 support?

SDL Development
1

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

Thoughts?

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

2

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

Thoughts?

Yes… I think I have thoughts. I just don’t know what they are. :wink:

Actually, to be honest, I was kind of surprised to see SDL_mixer handling
MPEGs when it did, because I had always considered SMPEG the “MPEG/MP3”
library, and “SDL_mixer” the “mixing/WAV/MOD/MIDI” library.

Of course, I stick to MODs and WAVs when I use SDL_mixer, so for me,
requiring one less download is nice… other’s may disagree.

-bill!

3

Yes… I think I have thoughts. I just don’t know what they are. :wink:

Actually, to be honest, I was kind of surprised to see SDL_mixer handling
MPEGs when it did, because I had always considered SMPEG the “MPEG/MP3”
library, and “SDL_mixer” the “mixing/WAV/MOD/MIDI” library.

Of course, I stick to MODs and WAVs when I use SDL_mixer, so for me,
requiring one less download is nice… other’s may disagree.

I’m thorougly in agreement.
I always use mod’s and wavs too, and feel that if I’m going to add
more/other types, I might as well compile with the options myself or use
another library to ‘add-on’ the features.

I thought that was generally the goal with SDL and its related libraries as
well. SDL is simple, and if you want to load complicated image formats use
sdl_image, and for more complicated audio use mixer, and then I think for
even more complex audio/visual commands go with an mpeg extension, etc, etc._________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

4

“Sam Lantinga” schrieb im Newsbeitrag news:E14l5dF-00086r-00 at roboto.devolution.com…

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

Thoughts?

My opinion is: Let it as it is :=) SDL_mixer is the LIB for WAV/MOD/MIDI and
SMPEG the one for MP3.> See ya,

-Sam Lantinga, Lead Programmer, Loki Entertainment Software

5

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

If lots of people download binaries from SDL and few compile,
→ include mp3; thereby people assume it works.
If binary distributions include the binaries from this site
→ also include mp3; this again will encourage that it works.

If folks complain about dependencies on smpeg
→ maybe disable

Now, I don’t think I’ve ever seen a complaint -against- smpeg being
included. My memory isn’t perfect though g.

do game folks deliver their own binaries, or just the packages from these
pages? If the latter, I think it’d be a more careful decision - but I
suspect the former is the normal case.

G’day, eh? :slight_smile:
- TeunisOn Thu, 5 Apr 2001, Sam Lantinga wrote:

6

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)
The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

Thoughts?

Is there a way to conciliate these two opposite goals ?
I think SDL_mixer should not force anyone to install anything else but the
main binaries

But indeed such an option will prouve itself usefull when we get hardware
MP3 support.

SDL_mixer’s mp3 functionnalities should rely on a hardware layer as well as
an emulation layer and programmers should be able to know wether mp3 support
is available and wether it is hardware accelerated or not.-----------

  • Jez.L -

Une station de m?tro, c’est l’endroit o? le m?tro s’arrete.
Une station d’autobus, c’est l’endroit o? le bus s’arrete…
Devant moi, j’ai une station de travail :slight_smile:

7

Hi,

Is there a really need for this? Why then you don't add ogg as well? I

actually think it is good as it is, because those who want mp3, they can do
this little #define blablabla and link with smpeg. Better it would be, if
there were binaries for smpeg available (are they alreay?)…

Kovacs

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows?
BeOS?)> > The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

Thoughts?

8

I’m building the official SDL_mixer 1.2.0 packages, and I’m
wondering
whether or not to include MP3 support by default? (Linux?
Windows? BeOS?)
The advantage is that if your application uses SDL_mixer’s MP3
support,
people who download the binary packages will get it working for
free.
The disadvantage is that the SDL_mixer binary runtime will require
the
user to also install the SMPEG binary runtime.
I think SDL_mixer should not force anyone to install anything else
but the
main binaries

I second this, however, maybe we’d be able to rip out the MPEG 1 Layer
3 sound decoder from SMPEG and link it directly in SDL_mixer. SMPEG
would then be a video (with or without sound) MPEG decoding library.
That is, unless this split results in the same code in two places
(since, say, some MPEG movies actually use MPEG 1 Layer 3 for their
sound)…

SDL_mixer’s mp3 functionnalities should rely on a hardware layer as
well as
an emulation layer and programmers should be able to know wether mp3
support
is available and wether it is hardware accelerated or not.

This brings up an idea: is SDL_mixer hardware-accelerated? I mean,
if it’s rendering a MOD, and hardware mixing is available on that
computer, will it use it?

Anyway, to get back on topic, how many sound
cards/motherboards/chipsets support MP3 acceleration? (rather, what
percentage of the users have one)–

Olivier A. Dagenais - Software Architect and Developer

9

In article ,
slouken at devolution.com says…

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

Thoughts?

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Rename SDL_mixer to SDL_sound and add MPEG support right into it.--

-dv

10

This brings up an idea: is SDL_mixer hardware-accelerated? I mean,
if it’s rendering a MOD, and hardware mixing is available on that
computer, will it use it?

… in fact, Will developpers be able to obtain hardware mixing specs on
systems without official drivers or hardware abstraction layers ( like
DirectX and QuickTime ) ?
For example, Linux community will probably never have Dream DSP and
Guillemot / Hercule’s products specs.

Anyway, to get back on topic, how many sound
cards/motherboards/chipsets support MP3 acceleration? (rather, what
percentage of the users have one)

Even if not many sound cards actually support MP3 acceleration, such a
percentage will increase.
SDL must probably keep looking after new technologies and must be a step
ahead or we’ll spend time updating continuously our sources.-----------

  • Jez.L -

Une station de m?tro, c’est l’endroit o? le m?tro s’arrete.
Une station d’autobus, c’est l’endroit o? le bus s’arrete…
Devant moi, j’ai une station de travail :slight_smile:

11

In one respect, I do not like it that the previous RPM binaries for SDL_mixer
required SMPEG. For Tux Typing, it seemed silly to require users to also have
SMPEG if they were installing from the binary RPMs, and I’m sure other authors
would feel the same (when their apps do not use MP3s at all).

In another respect, for those projects that do need SMPEG, it might complicate
things for the intended end-user if this weren’t the case.

Perhaps on the main SDL site you should just continue doing what has been done
before (include MP3 support in SDL_mixer), and allow others to create binary
packages without that support (then store them eslewhere, for example, RPMs on
rpmfind.net and BeOS binaries on BeBits) for those who really don’t want it.On Thu, 05 Apr 2001, you wrote:

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

Thoughts?

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

12

Rename SDL_mixer to SDL_sound and add MPEG support right into it.

This would be very nice, yes. I myself would like to have a single
sound support library. But SDL is still missing a decent midi player
support :confused: IMHO, sound, or audio, is much better than mixer, and
that MIDI is important media too.

– Timo Suoranta – @Timo_K_Suoranta –

13

“Sam Lantinga” wrote

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

i have to go with the crowd here, and recommend not forcing
the dependency. (although i have done it in my prebuilt win32 libs)

for down the road…

i hope some of the core functionality of SDL_mixer can be included
in the core SDL-1.3 library. this way the logic is done by SDL,
but the various file-loaders can be a separate library.
(after all, there is no SDL_blit libraray for gfx/etc)
(ok, not a perfect analogy, but i think it explains…)

also, i know there’s been talk of cross-platform shared library
loaders in SDL. if this were a feature, then SDL_mixer could
just try to find SMPEG at runtime, and if found, enable MP3.
this seems like it would be the best of both worlds.

14

i have to go with the crowd here, and recommend not forcing
the dependency. (although i have done it in my prebuilt win32 libs)

Sounds good, it shall be done.

for down the road…

i hope some of the core functionality of SDL_mixer can be included
in the core SDL-1.3 library. this way the logic is done by SDL,
but the various file-loaders can be a separate library.
(after all, there is no SDL_blit libraray for gfx/etc)
(ok, not a perfect analogy, but i think it explains…)

also, i know there’s been talk of cross-platform shared library
loaders in SDL. if this were a feature, then SDL_mixer could
just try to find SMPEG at runtime, and if found, enable MP3.
this seems like it would be the best of both worlds.

Yep. It’s one of the plans for 1.3

Thanks everybody! :slight_smile:

-Sam Lantinga, Lead Programmer, Loki Entertainment Software
15

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

I last time I tried to cross compile SDL_mixer for Windows (a few weeks ago)
using the latest versions, SDL_mixer would not build with SMPEG support
because it could not find SMPEG, even though it was cross compiled and
installed already. If this is still the case, I’d definitely like the
prebuilt version to have SMPEG compiled in.

16

[clip]
(with a note that the sound layer and video layers of smpeg don’t strike
me as being able to be seperated easily - they share a core with seperate
drivers… but I didn’t write 'em so what do I know :slight_smile:

SDL_mixer’s mp3 functionnalities should rely on a hardware layer as
well as
an emulation layer and programmers should be able to know wether mp3
support
is available and wether it is hardware accelerated or not.

This brings up an idea: is SDL_mixer hardware-accelerated? I mean,
if it’s rendering a MOD, and hardware mixing is available on that
computer, will it use it?

nope. For the most part, most sound cards can’t accelerate mod files
anyways - noteable exceptions are Gravis Ultrasound/family, the SB/32+
family (SB/32, SB/64, SB/128, SB/live).
I haven’t seen any others recently - there have been very few soundcards
that supported uploading samples.

Most modern sound cards seem to prefer to put more work onto the CPU - my
current soundcard (not my GUS sigh) has two DSP’s - one for sound
sampling, and one for MIDI emulation aka timidity/mikmod/SDL_Mixer :slight_smile:

Anyway, to get back on topic, how many sound
cards/motherboards/chipsets support MP3 acceleration? (rather, what
percentage of the users have one)

I’ve never -heard- of a system with MP3 acceleration.
Drivers - yes. Computer hardware outside of a specialized device (eg: mp3
player) - no. but an mp3 can play on a 486-100 in stereo… (and a
486-50 in mono - I know this from experience :slight_smile: It’s not as high load as
many current systems… (eg: the divx codec that’s so popular amongst
certain crowds)

G’day, eh? :slight_smile:
- TeunisOn Thu, 5 Apr 2001, Olivier Dagenais wrote:

What is courage now? Is it just to go until we’re done?
Men may call us heroes when they say we’ve won but if we should fail, how
then… What is courage now?
- Fellowship Going South by Leslie Fish sung by Julia Ecklar

Member in purple standing of the Mad Poet’s Society.
Trying to bring truth from beauty is Winterlion.
find at this winterlions’ page

17 
Rename SDL_mixer to SDL_sound and add MPEG support right into it.

This would be very nice, yes. I myself would like to have a single
sound support library. But SDL is still missing a decent midi player
support :confused: IMHO, sound, or audio, is much better than mixer, and
that MIDI is important media too.

umm - SDL_Mixer includes timidity… although it doesn’t come with the
timidity sample library. timidity is a -very- nice MIDI engine…
although SDL_Mixer has no support for -external- MIDI (eg: sound cards
with built-in MIDI (roland series eg) or external MIDI systems such as
keyboards or such)

umm → Are there any libraries for working with external MIDI? I’ve
haven’t seen any support for windows MIDI or linux MIDI outside of
emulation in a while, so I’m curious about this… after all, I just
picked up some MIDI adapter cables for my sb-16 and am going to be getting
a keyboard :slight_smile:

G’day, eh? :slight_smile:
- TeunisOn Thu, 5 Apr 2001, Timo K Suoranta wrote:

18

I second this, however, maybe we’d be able to rip out the MPEG 1 Layer
3 sound decoder from SMPEG and link it directly in SDL_mixer. SMPEG
would then be a video (with or without sound) MPEG decoding library.
That is, unless this split results in the same code in two places
(since, say, some MPEG movies actually use MPEG 1 Layer 3 for their
sound)…

Seems like a good idea to me.

Anyway, to get back on topic, how many sound
cards/motherboards/chipsets support MP3 acceleration? (rather, what
percentage of the users have one)

Probably almost none, however I think nearly everyone is missing the point.
You shouldn’t be looking at the situation right this exact moment in time and
decide based on that. We are talking about a library, which will be the
foundation of other programs from now until some point in the future.
Therefore you have to consider what changes are likely to occur in the future.

I think mp3 is going to start finding their way into games in the future.
Exactly when I’m not sure, though. I think high end machines could handle it
fine right now, but low end machines probably can’t. So for people designing
games for the widest market, they need to have a pretty low minimum
requirements. So these developers probably won’t be using mp3s in games for
another 2 years or so I’d guess. So it may be too early still to have mp3
support in my default right now. Maybe wait about 6 months or a year and
then make it included by default.

19

I’ve never -heard- of a system with MP3 acceleration.
Drivers - yes. Computer hardware outside of a specialized device (eg: mp3
player) - no. but an mp3 can play on a 486-100 in stereo… (and a
486-50 in mono - I know this from experience :slight_smile: It’s not as high load as
many current systems… (eg: the divx codec that’s so popular amongst
certain crowds)

Doulder (www.doulber.com) use MP3 as music, and has a perfect 2 layers
scroller

Gautier
www.tlk.fr

20

Sam Lantinga wrote:

I’m building the official SDL_mixer 1.2.0 packages, and I’m wondering
whether or not to include MP3 support by default? (Linux? Windows? BeOS?)

The advantage is that if your application uses SDL_mixer’s MP3 support,
people who download the binary packages will get it working for free.

The disadvantage is that the SDL_mixer binary runtime will require the
user to also install the SMPEG binary runtime.

The user is always able to custom build SDL_mixer with or without MP3
support themselves.

Thoughts?

I worked on such a implementation using three different approaches: SMPEG,
mpg123 and now xaudio.

I found smpeg not an optimal solution for pure MP3 playback as it has the
added MPEG1 ballast (large lib), did not support rate conversion on the fly
(a feature that I found too hard to add to the SMPEG source) and it had
problems when seeking in MP3 streams (decoding thread lost the stream
synchonization and stopped playback).

The lib code that is part of mpg123 is outdated and the main code mpg123
itself works well, but is GPLed which is not a good match with the LGPLed
SDL. Maybe SAM can get the author of mpg123 to relax the license for use in
SDL. Nevertheless, this would be a good solution for GPLed SDL projects.

xaudio (www.xaudio.com) is binary only, cross-platform and free but one has
to sign a disclaimer type license to be able to use it. It hast a SYNC
interface to get at the data and an ASYNC interface that does all the playing
by itselfg. I am using that right now as it seems the most stable and
compact.

I think it might be worth it to actually create a seperate SDL_MP3 library
that will handle different input source libs (as listed above) and does MP3
to memory loading as well as rate conversion on the fly and provides an easy
to use SDL_Mixer interface.

My 0.02 cents.
Andreas–
| Andreas Schiffler aschiffler at home.com |
| Senior Systems Engineer - Tek21 Inc., Buffalo |
| 4707 Eastwood Cres., Niagara Falls, Ont L2E 1B4, Canada |
| +1-905-371-3652 (private) - +1-905-371-8834 (work/fax) |