[sdlsound] Looking for advice for creating proper Sound_AudioInfo

Ryan C. Gordon icculus at clutteredmind.org
Sat Oct 4 23:17:41 EDT 2003

> I've kicked around the idea about always picking
> target.format as AUDIO_S16SYS or AUDIO_U16SYS.
> However, this seems like a waste of memory and extra
> processing to me since OpenAL is supposed to be able
> to handle 8-bit samples. I'm also unclear of what the
> impact is of picking between signed and unsigned (i.e.
> if it really matters, or is there an optimal value for
> OpenAL).

This is awkward for several reasons:

1) OpenAL 1.0 doesn't support all of the data formats you'd expect (8 
bit data is always unsigned, SDL can give you 8-bit signed, etc).
2) SDL doesn't support every format that the hardware wants (the OSX 
audio API, CoreAudio, eventually wants you to feed it Float32 format 
data...there isn't an AL_FORMAT_FLOAT32, so there _will_ be a conversion 
no matter what).
3) OpenAL doesn't tell you what format the audio hardware really wants, 
and gives you no way to force it to a given format.

The idea with OpenAL is to treat audio data like OpenGL treats 
textures...the "upload" is considered expensive, so you should do it 
once, preferably at level startup when you won't have to take a 
framerate hit, and let the implementation convert to it's desired format 
internally. After you've uploaded via alBufferData(), you shouldn't have 
a continued performance hit for playback of that data.

This, of course, is a bit more awkward for streaming audio via buffer 
queues, since you're continually calling alBufferData, but there's not 
much to be done here. Ideally, there would be AL extensions for each 
supported format, like the existing AL_EXT_vorbis (which, besides 
removing the burden of decoding from the application, can actually be a 
significantly faster path when the implementation handles the format 


More information about the sdlsound mailing list