I’ve recently started porting some directsound stuff, and have run into
a few questions about the SDL_mixer library:
What is the rationale behind the maximum number of channels being set
to 8? Would it be worth adding a function to allow apps to up this
limit?
The game I’m hacking about on would probably benefit from more channels.
The original directsound version uses up to 32 channels, each with
stereo panning. On a decent sound card under dsound, I think most of the
mixing is done by the hardware. Even my crappy little no-namebrand
soundcard can mix 8 channels in hardware.
Can SDL take advantage of hardware mixing? From looking at the audio
code, it looks like everything is mixed in software.
Actually, I’m not sure if hardware mixing is even such a big win these
days - CPUs are getting pretty zippy. Also, there are a lot of cool
effects you can do with software…
Would I be better off just ditching the SDL audio support and just
going to OpenAL?
Probably somewhat overkill for a non-3d sound system, but the API looks
really nice to work with…
I’ve recently started porting some directsound stuff, and have run into
a few questions about the SDL_mixer library:
What is the rationale behind the maximum number of channels being set
to 8? Would it be worth adding a function to allow apps to up this
limit?
I think it’s completely and utterly random. I don’t know if I’ll have to change this to do some of the OpenAL wrapping stuff which I’m
supposed to be doing this evening …
Can SDL take advantage of hardware mixing? From looking at the audio
code, it looks like everything is mixed in software.
AFAIK SDL_Mixer overlaps SDL’s audio functions which simply interface out to other libraries (OSS, DirectSound, ESD, Whatever). I
wouldn’t mind seeing the channel support glopped into SDL instead of SDL_Mixer, and then using whatever those libraries recommend, if
they do recommend. Hmm… I honestly can’t remember if SDL_MixAudio or whatever it’s called uses hardware if possible.
Would I be better off just ditching the SDL audio support and just
going to OpenAL?
Probably somewhat overkill for a non-3d sound system, but the API looks
really nice to work with…
Nah, I’m doing it too – I’m even extending my game’s audio support to now use 3D audio! OpenAL rocks my worl;d.
Really, after all’s said and done, SDL_Mixer is sort of a bunch of hacks stacked on top of SDL. I’m saying OpenAL since it’s got a better,
more thought out API, and probably has… OK, will have … better cross platform sound support. So explain why I volunteered to bind OpenAL
on top of SDL_Mixer?
as the 8 channels and doesnt suport hardware, wouldnt it make more sense to implement openAL ontop of SDL’s sound stuffs instead of SDL_mixer’s
(and make whatever additions are necesary in SDL’s sound suport). that would also get rid of the extra dependency. if this is a bad idea please
forgive my ignorance on the subject. (and if its a good one then just forget that i dont know much about it and think im smart
Jess
vining at pacificcoast.net wrote:> >I’ve recently started porting some directsound stuff, and have run into
a few questions about the SDL_mixer library:
What is the rationale behind the maximum number of channels being set
to 8? Would it be worth adding a function to allow apps to up this
limit?
I think it’s completely and utterly random. I don’t know if I’ll have to change this to do some of the OpenAL wrapping stuff which I’m
supposed to be doing this evening …
Can SDL take advantage of hardware mixing? From looking at the audio
code, it looks like everything is mixed in software.
AFAIK SDL_Mixer overlaps SDL’s audio functions which simply interface out to other libraries (OSS, DirectSound, ESD, Whatever). I
wouldn’t mind seeing the channel support glopped into SDL instead of SDL_Mixer, and then using whatever those libraries recommend, if
they do recommend. Hmm… I honestly can’t remember if SDL_MixAudio or whatever it’s called uses hardware if possible.
Would I be better off just ditching the SDL audio support and just
going to OpenAL?
Probably somewhat overkill for a non-3d sound system, but the API looks
really nice to work with…
Nah, I’m doing it too – I’m even extending my game’s audio support to now use 3D audio! OpenAL rocks my worl;d.
Really, after all’s said and done, SDL_Mixer is sort of a bunch of hacks stacked on top of SDL. I’m saying OpenAL since it’s got a better,
more thought out API, and probably has… OK, will have … better cross platform sound support. So explain why I volunteered to bind OpenAL
on top of SDL_Mixer?
I’ve recently started porting some directsound stuff, and have run into
a few questions about the SDL_mixer library:
What is the rationale behind the maximum number of channels being set
to 8? Would it be worth adding a function to allow apps to up this
limit?
It’s already in the API :
/* Dynamically change the number of channels managed by the mixer.
If decreasing the number of channels, the upper channels are
stopped.
This function returns the new number of allocated channels.
*/
extern DECLSPEC int Mix_AllocateChannels(int numchans);
The game I’m hacking about on would probably benefit from more channels.
The original directsound version uses up to 32 channels, each with
stereo panning. On a decent sound card under dsound, I think most of the
mixing is done by the hardware. Even my crappy little no-namebrand
soundcard can mix 8 channels in hardware.
Can SDL take advantage of hardware mixing? From looking at the audio
code, it looks like everything is mixed in software.
That’s true, the mixer uses SDL_MixAudio(), which is entirely software for
now…–
Stephane Peter
Programmer
Loki Entertainment Software
“Microsoft has done to computers what McDonald’s has done to gastronomy”
/* Dynamically change the number of channels managed by the mixer.
If decreasing the number of channels, the upper channels are
stopped.
This function returns the new number of allocated channels.
*/
extern DECLSPEC int Mix_AllocateChannels(int numchans);
Doh!
Will have to go through the headers a bit more carefully in future.
That’s true, the mixer uses SDL_MixAudio(), which is entirely software for
now…
Cool and groovy with me -
Our audio guy did some basic profiling (under directsound) a while back,
and he is of the opinion that software mixing really isn’t a very big
hit on the sort of CPUs we have these days…
Nah, I’m doing it too – I’m even extending my game’s audio support to now use 3D audio! OpenAL rocks my worl;d.
I think I’ll probably do an OpenAL version as well, mainly for the
experience and to give OpenAL a bit of an evaluation for other projects.
It’ll be interesting to see how enthusiatic other hardware companies are
about OpenAL. I suspect there’ll be a lot of politics going on behind
the scenes, but I think Creative Labs probably have enough clout to
bully everyone else into doing the right thing too
OpenAL does look nice… mmmmmm… function-based API…
Antipodean Straggler? Wuzzat?
One of those people from the Antipodean regions (New Zealand in my case)
who end up working/living in odd places about the globe. Usually pubs in
London.
That’s true, the mixer uses SDL_MixAudio(), which is entirely software for
now…
Cool and groovy with me -
Our audio guy did some basic profiling (under directsound) a while back,
and he is of the opinion that software mixing really isn’t a very big
hit on the sort of CPUs we have these days…
Particularly if you use some easy assembler, like add with carry, then
check the carry instead of a C language “if” to do the clipping. MMX can
be helpful also, but the add with carry thing works everywhere and is a
BIG step from C-only implementation.
The C-only implementation is already nice on only slightly powerful
machines, mind you, but I have this 486 at home… :-)–
Pierre Phaneuf
Systems Exorcist
That’s true, the mixer uses SDL_MixAudio(), which is entirely software for
now…
Cool and groovy with me -
Our audio guy did some basic profiling (under directsound) a while back,
and he is of the opinion that software mixing really isn’t a very big
hit on the sort of CPUs we have these days…
Particularly if you use some easy assembler, like add with carry, then
check the carry instead of a C language “if” to do the clipping. MMX can
be helpful also, but the add with carry thing works everywhere and is a
BIG step from C-only implementation.
The C-only implementation is already nice on only slightly powerful
machines, mind you, but I have this 486 at home…
I don’t think there is such a thing as “easy” assemlber in a
cross-platform api.
Long live the confused,
Akawaka.On Thu, 6 Apr 2000, Pierre Phaneuf wrote:
Particularly if you use some easy assembler, like add with carry, then
check the carry instead of a C language “if” to do the clipping. MMX can
be helpful also, but the add with carry thing works everywhere and is a
BIG step from C-only implementation.
The C-only implementation is already nice on only slightly powerful
machines, mind you, but I have this 486 at home…
I don’t think there is such a thing as “easy” assemlber in a
cross-platform api.
Huh? glibc uses assembler routines and is cross-platform. The only thing
is that a C implementation should be “fast enough”. If there is an
assembler implementation that works on the platform you are compiling
on, it should be used instead (look at memcpy for example).
As long as the assembler loop is hidden from the application using it,
it’s okay.
Asking the application programmer to do some assembler is a whole other
thing! This wouldn’t be acceptable.–
Pierre Phaneuf
Systems Exorcist
