Re: Problem with alSourceUnqueueBuffers

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

What OpenAL device are you using, and which OS and soundcard?

Buffer underrun is the most likely problem I think.  In your testing are
you able to confirm that Buffers Processed never returns the same number of
Buffers that are actually queued on the Source at the moment?

For the first iteration how many Buffers are you filling with the 2205
samples?

Are you using get playback offset to determine how many samples to fill?
I would recommend using a fixed buffer size for the streaming operations
rather than trying to compute how many samples have been played.   The get
sample offset call is tricky to use because it returns an offset from the
start of the buffer queue - not the offset in the current buffer.   So, I
would use, say 4 x 25ms buffers and as and when a buffer is processed,
unqueue it, fill it with 25ms of audio data, and requeue it.

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

So if you keep generating, filling, and requeueing new Buffers the Source
keeps playing without any problems?  Does it play without glitches?  Some
implementations of OpenAL enable a starved Source to automagically restart
playing if the application never actually queries the playback state and
just queues new buffers on it.

Dan

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