[sdlsound] Looking for advice for creating proper Sound_AudioInfo

[Eric Wing]

Hmmm, thanks for the detailed response. You've given
me some things to think about. I'm writing code that
deals with both predecoded samples and buffer
queueing. In either case though, I was hoping to write
the code in the best possible way and be done with it.


In the absence of an ideal solution, I still seem to
be stuck between my original choices. I currently
don't have the time to modify SDL to support more
formats nor can I write all the AL_EXT's I need. 

So it looks like I must let SDL(_sound) convert it to
something usable that OpenAL can read, and then let
OpenAL do the final conversion to it's own needs. The
question is, what is the best format for SDL to
convert to for OpenAL to handle. 

My original idea was to let SDL convert it to a 8 bit
or 16 bit depending on the format of the data, hoping
that in the case of 8 bit, that I save some memory and
performance by avoiding an unnecessary 16 bit
conversion in SDL (and hope hardware can handle it
better if it needs to convert it again), but this is
where I ran into a roadblock with RWops.

You mentioned that 8-bit data is always unsigned. Is
16-bit data always unsigned? It seems that my only
option now for the general case is to always convert
to 16 bit since I can't predetermine the bitdepth
before load. In this case, should I pick signed or
unsigned?

Thanks,
Eric


--- "Ryan C. Gordon" <icculus at clutteredmind.org>
wrote:
> 
> > 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 
> directly).
> 
> --ryan.
> 
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com