[Openal] Streaming audio data segments vs. uploading entire sound
at once
Mik Fig
mikfig27 at gmail.com
Wed Jun 3 23:33:27 PDT 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal/attachments/20090603/e87376eb/attachment.html
More information about the Openal
mailing list