[Openal] Re: Streaming audio data segments vs. uploading entire sound at once

[Mik Fig]

>> I have a question inspired by qartar's problem with streaming to the
>> buffers. I was wondering what kind of performance benefits might result
>> from streaming blocks of data rather than uploading the entire sound
file.
>> In what cases might such a solution have great benefit and in what
>> situations might it just be useless?

> Streaming is mostly helpful for when the sound is large (at least a few
> megabytes uncompressed), since it doesn't have to hold the whole
uncompressed
> file in memory, or read/decompress the whole file at once before playback
can
> start. Hardware devices can have memory restrictions, too.

> Some implementations may also have restrictions that can cause integer
> overflows.. eg. if the current position of a sound is tracked using a
22.10
> fixed-point integer, that only leaves 22 bits to represent the
whole-sample
> position. 22 bits can hold a value up to 4,194,304, so a buffer that has
more
> than a couple million samples may risk having the position value overflow
and
> wrap around back to 0 before it can finish.. or the end point itself can
wrap
> around, so only part of the beginning is played before stopping.

> Shorter sounds won't really benefit from streaming though, and may
actually be
> a detriment, if the overhead of buffer queues and such are more costly
than
> simply loading it all at once. Streaming is also detrimental because the
> buffers can't be as easily reused and shared among multiple sources.

> IMO, most regular sound effects would be better not streamed, so they can
be
> cached in an OpenAL buffer for quick reuse. Music and long dialog may be
> better streamed, since they're going to be larger and more unique (they
won't
> be reused as often for caching to be any real benefit).

Thanks :D, just the kind of answer I was looking for.

-Mikfig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal/attachments/20090604/83cdfc89/attachment.html