Streaming audio data segments vs. uploading entire sound at once

[mikfig]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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?

Here is the original question:

I am trying to implement a streaming sound engine with OpenAL by uploading
small blocks of sound data into buffers as needed instead of the entire
sound at once. Doing this requires a lot of buffers queued onto one source
so I tried to reuse processed buffers when available instead of creating a
new buffer for each block of data. The update loop looks something like
this...

alGetSourceiv( source, AL_BUFFERS_PROCESSED, &count );

if ( count ) {
       alSourceUnqueueBuffers( source, 1, &buffer );
} else {
       alGenBuffers( 1, &buffer );
}

alBufferData( buffer, ... );
alSourceQueueBuffers( source, 1, buffer );

It seems that whenever I use alSourceUnqueueBuffers the source is stopped or
otherwise no longer plays the data queued. This causes any sounds longer
than the initial few buffers (about two tenths of a second worth) to stop or
fail to play entirely. Even if not using the buffer from
alSourceUnqueueBuffers  or calling alSourcePlay afterwards the problem
persists. No errors are being generated. This problem can be circumvented by
not calling alSourceUnqueueBuffers and generating new buffers for each sound
segment.

The questions I have are, is there a significant performance gain from
uploading one buffer per source as opposed to uploading segments at a time?
Is there some functionality of alSourceUnqueueBuffers that I am missing
which is causing this problem?

Thanks,
Mikfig

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[Chris Robinson-5]

On Wednesday 03 June 2009 11:33:27 pm Mik Fig wrote:
> 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).
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

[mikfig]

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

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal