[sdlsound] SDL_sound 2.0 details revealed!

Tyler Montbriand tsm at accesscomm.ca
Fri Jul 30 14:55:51 EDT 2004

On Thursday 29 July 2004 16:51, Ryan C. Gordon wrote:
> > 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.
> Well, with the exception of the callbacks, this all happens behind the
> scenes, so we could have an integer path for embedded devices that
> doesn't make promises about clipping. Is it reasonable to have 32-bit
> integer mixing, or should we target 16-bit for these devices?
Depends what you mean by 'target'.  The native audio output format is going to 
be, at best, 16-bit 44100Hz stereo.  These things use intel strongarm/xscale 
processors, though, which are fully up to the task of 32-bit mixing, 32-bit 
integers being their native format.  It's floating point that kicks them in 
the head;  they have no FPU, all of it is emulated in software.

> We'd have to figure out something with the post-mix callbacks, though.
> Part of the reason for the float32 mixer is CoreAudio, but part of it is
> application convenience...there's nothing worse than having to write 12
> codepaths for all the different audio formats you might have to process.
If we had to pick one audio format for all mixing, I'd pick 32-bit signed 
integer.  It's big enough to encompass every other audio format from 8 to 24 
bit signed and unsigned, everyone knows what it is and how to use it, and any 
processor worth beans can handle it natively.

> > Is Sound_MixInit calling SDL_Init and related calls for us, or are they
> > omitted for clarity?
> I haven't decided, honestly. It'll definitely call SDL_OpenAudio() for
> obvious reasons. The "NULL" is there in case you want to open the device
> in a specific format (but then do we force SDL to emulate that format if
> the hardware doesn't support it directly, etc).

My suggestion would be to not mess with SDL too much.  The more things we do 
for user convenience, the more users have to peek inside the source itself to 
figure out just what the heck it's doing behind their backs ;)

More information about the sdlsound mailing list