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

[Jan Wassenberg]

Hello Chris,

thanks for your quick reply!

> The issue is, while the source is marked as looping it won't set any  
> buffers as processed. Once looping is unset, OpenAL Soft will tell you
> how many buffers have been played, but their internal status won't
> have been marked as processed yet.
Ah, I see.

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

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

> As an aside, it looks like there might be an issue in vsrc_latch. If a  
> source is used and made relative, its rolloff factor is set to 0.
> But if the source is re-used and made not relative, its rolloff factor
> will be left at 0.
Thanks very much for pointing this out!
I've fixed this as follows:
alSourcef (vs->al_src, AL_ROLLOFF_FACTOR,   vs->relative? 0.0f : 1.0f);

Best Regards
Jan