[sdlsound] SDL_sound 2.0 details revealed!

[Tyler Montbriand]

This sounds very promising.  Lemme break my long silence and inject a few 
comments.  :)

On Thursday 29 July 2004 03:36, Ryan C. Gordon wrote:
>  - No clamping at mix time. Most SDL-based mixing is done via
> SDL_MixAudio(), which mixes two samples together, clamping to 16-bits, and
> then mixes the next sample into this already-clamped buffer. This can lead
> to audio distortion. SDL_sound mixes all samples into a 32-bit floating
> point buffer before passing it to the audio device, which means no
> unnecessary clamping. It also means it can be more optimized for MacOS X's
> CoreAudio and other next-gen audio subsystems, which require you to feed it
> float32 data.
Does this mean we're abandoning small devices without FPUs, like my ipaq?  
44100*2 pointless software-emulated conversions to floating point and back 
per second would grind it to a halt.

Could we compromise at 32-bit integer mixing, and conversion to floating point 
as necessary?  Unlike floating point, no accuracy is lost when adding 
together integers, and I think a limit of 65,535 maximum 16-bit "channels" is 
more than reasonable.

>  - No "channels". If you want to mix 1,000 audio files and have the
> hardware to cover it, you can. You don't have to manage playback channels.
How is volume, total and per playing sound, controlled without channels?

Can you limit the maximum number of sounds playing at the same time?  I don't 
see the ability to mix 1000 simultaneous sounds as something to be desired, 
since every individual sample would be completely inaudible.

>  - Can handle non-power-of-two resampling. If your samples are at 8000Hz
>    and the audio hardware is at 11000Hz, this doesn't cause output
> problems.
YES.  We want it and SDL doesn't have it.

>  - It can be compiled out if you just want the 1.0 API for decoding
> formats. (initializing the mixer subsystem in this case will fail, but for
> binary compatibility, the entry points will still exist).
Just as devil's advocate, if it's not integral to SDL_sound, why build it into 
it instead of making it an add-on library?

> Example #1: Play a sound and get the heck out of there.
>
> #include "SDL_sound.h"
>
> int main(int argc, char **argv)
> {
>     Sound_MixInit(NULL);  // start the mixer; don't care what format.
>     Sound_Sample *hello = Sound_NewSampleFromFile("hello.wav", NULL,
> 10240); Sound_MixPlay(hello);
>     while (Sound_MixPlaying(hello))
>         SDL_Delay(100);  // wait around; mixing is in a seperate thread!
>     Sound_FreeSample(hello);
>     Sound_MixDeinit();
>     return(0);
> }
Is Sound_MixInit calling SDL_Init and related calls for us, or are they 
omitted for clarity?

> Example #2: Mixing two sounds.
>
> #include "SDL_sound.h"
>
> int main(int argc, char **argv)
> {
>     Sound_MixInit(NULL);  // start the mixer; don't care what format.
>     Sound_Sample *hello = Sound_NewSampleFromFile("hello.wav", NULL,
> 10240); Sound_Sample *music = Sound_NewSampleFromFile("icculus.ogg", NULL,
> 10240); Sound_MixPlay(music);
>     while (Sound_MixPlaying(music))
>     {
>         if (!Sound_MixPlaying(hello))
>         {
>             Sound_Rewind(hello);
>             Sound_MixPlay(hello);
>         }
>         SDL_Delay(100);  // wait around.
>     }
>     Sound_FreeSample(music);
>     Sound_FreeSample(hello);  // will stop if it happens to still be
> playing. Sound_MixDeinit();
>     return(0);
> }
>
> You might notice that we called Sound_Rewind() on the hello sample. This
> isn't part of the mixer itself, and is a function from SDL_sound v1, before
> there was a mixer at all. This illustrates that you can use the usual
> SDL_sound methods to manipulate a sample in the mixer, including seeking
> and predecoding. These are safe operations even while the sample is
> playing.

That is an elegant and powerful way to tie SDL_sound and the mixer together, 
but I see one big limitation:  What if you want to have several instances of 
'hello' being played at the same time?  Will you have to load it into memory 
several times to get different Sound_Samples to tell them apart?

> Basic attribute #3: Per-channel Gain.
>
> If you can tweak the volume of the left or right channel on a sample, you
> can accomplish (or at least fake) a surprising number of simple sound
> effects. Therefore the mixer allows you to do just this, and then builds a
> few features on top of this magic.
>
> This is accomplished by tweaking the "gain" of a given channel. "Gain" is
> just a fancy way of saying "volume". You specify it as a floating point
> number, usually in the range of 0.0f to 2.0f. If you set the gain to 0.0f,
> it results in silence, and 1.0f results in no change at all. 0.5f halves
> the volume and 2.0f doubles it. As you might have guessed, the sample gets
> multiplied by this value.

I'd suggest allowing a range of -2.0f to 2.0f, or perhaps -32767 to +32767 if 
we do integer mixing.  You can do some nifty pseudo-surround effects by 
inverting one stereo channel.