[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
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