[Openal-devel] Questionable "invalid value" from alSourceUnqueueBuffers

[Chris Robinson]

On Tuesday 11 August 2009 1:13:20 pm Jan Wassenberg wrote:
> > So if [..] runs before the mixer next updates the source,
> > AL_BUFFERS_PROCESSED
> > will see finished buffers that aren't marked as processed. Oddly, I can't
> > see how this would happen in your snd_mgr.cpp, but that's what I'm seeing
> > in the trace.
>
> OK, I've sifted through the trace and reconstructed what is happening in
> the game. A much shorter and annotated version is available at
> http://trac.wildfiregames.com/attachment/ticket/297/annotated_trace.txt .
> This has helped understand what is happening:
> 1) the main menu track starts playing with loop=true;
> 2) at some point we want to stop it after fading out;
> 3) after lowering its gain a couple of times,
> 4) it is eventually stopped and its buffer queue wiped out by setting
> AL_BUFFER to 0.
> 5) the AL source is returned to a stack,
> 6) from which it is taken and assigned to a short clip (which sets
> loop=false).
> 7) when the clip finishes playing and AL_BUFFERS_PROCESSED returns 1 (the
> 'new' buffer),
> 8) the old (still unprocessed) buffer from the previous version of the
> source
>     cannot be unqueued.
>
> My understanding is that the error in 8 is caused by not really removing
> all buffers/previous state in step 4.
> Is there anything else we can do to reset the source before reusing it for
> other buffers?

Given the annotated trace, what actually appears to be happening is that when 
the queue is erased by setting AL_BUFFER to 0, OpenAL Soft erroneously doesn't 
change the number of buffers played. So when you query AL_BUFFERS_PROCESSED, 
it returns 1 from the previous use even though the newly-queued buffer is 
still pending (as alSourcePlay isn't called again between step 5 and 7).

> > But if possible, you shouldn't set the source as looping if you're going
> > to unqueue buffers from it.
>
> hm, steps 5 and 6 look legitimate, I am told that sources should be reused
> rather than re-creating them (at least on Windows). Separate tracking of
> sources that were looping vs non-looping would be onerous, and switching
> to FIFO rather than LIFO reuse of sources might only delay this problem.
> Is there anything else we can do on the application side?

It's true that you should reuse sources. As a workaround, you can call 
alSourceRewind when the source is returned to the stack, which will clear the 
buffers played count. I got this fixed up in GIT, though.