Garin Hiebert wrote:
> You should also include code that
> checks that the Source is still playing, and if not, include logic
> to start
> it playing again.
This is why there are no errors returned, by the way. As far as
OpenAL is concerned, everything is fine. It runs out of data and then
stops the source just like it should. No error. ;-)
In summary, make two changes:
1) The implementation should be changed such that it has 100ms or so
of data available in multiple buffers (four or so seems "reasonable,"
but as few as two _should_ work).
2) Detect an "under-run" by looking for streams which have stopped
sources. When detected, buffer up a full set of buffers for that
source and do a Play on that source. In most products, this should be
a very rare occurrence, but may still happen during long disk access
or some other operation which stalls the engine for a while.
Garin
Thank you again for your replies. You seem to be focusing on buffer underrun issues. I went back to my code and added a check to be sure and it does not seem to be the issue. When a sound is played the engine determines how many samples ahead of the source it should be uploading, usually 100 milliseconds, and uploads that many samples, so on the first iteration 2205 samples are uploaded for a 22050 hz sound file, and then subsequent iterations are performed at approximately 60 hz. This works when not unqueueing buffers, but as soon as I unqueue a buffer, regardless of whether I delete or reuse that buffer, the sound stops playing.
