Questionable "invalid value" from alSourceUnqueueBuffers

[Jan Wassenberg]

Greetings,

I'm working on sound for the 0 A.D. project (www.wildfiregames.com/0ad)  
and have encountered an error on OpenALsoft implementations of OpenAL. The  
first time alSourceUnqueueBuffers is called upon to unqueue a single  
buffer, it raises an "invalid value" error, but not subsequently.

My understanding of the OpenAL Programmer's Guide (revision 1.2) is that  
alSourceUnqueueBuffers fails with "invalid value" iff a buffer can't be  
unqueued because it had yet to be processed. However, we are first  
checking alGetSourcei AL_BUFFERS_PROCESSED and receiving a nonzero count  
for that source.

The same code works without error on my Windows system with a Creative  
X-Fi and drivers ctaud2k.sys (5.12.01.1201-2.10.0760), OpenAL32.dll  
(6.14.0357.19), wrap_oal.dll (2.1.4.0), ct_oal.dll  
(5.12.01.1187-2.09.3060).

Due to the once-only mode of failure and because it works on Creative's  
OpenAL, I'm thinking the cause might lie in OpenALsoft. Both users that  
reported the error were using version 1.7.411. Was this an known error and  
would be fixed by upgrading to the most recent version?

A ltrace of the OpenAL calls is available at  
http://trac.wildfiregames.com/attachment/ticket/297/openal.trace . After  
init, the engine starts playing stereo buffers (music) and the error comes  
up at the end after having finished playing a short mono buffer (sound  
effects).

If it helps, our interface to OpenAL can be viewed at  
http://trac.wildfiregames.com/browser/ps/trunk/source/lib/res/sound/snd_mgr.cpp

Any help in diagnosing and solving the error would be appreciated.
Thanks in advance + cheers
Jan
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Monday 10 August 2009 11:37:46 pm Jan Wassenberg wrote:

> I'm working on sound for the 0 A.D. project (www.wildfiregames.com/0ad)
> and have encountered an error on OpenALsoft implementations of OpenAL. The
> first time alSourceUnqueueBuffers is called upon to unqueue a single
> buffer, it raises an "invalid value" error, but not subsequently.
>
> My understanding of the OpenAL Programmer's Guide (revision 1.2) is that
> alSourceUnqueueBuffers fails with "invalid value" iff a buffer can't be
> unqueued because it had yet to be processed. However, we are first
> checking alGetSourcei AL_BUFFERS_PROCESSED and receiving a nonzero count
> for that source.

Hi.

Looking at the call trace, it appears you initially set the source as looping,
then unset the looping flag before trying to unqueue the buffer.

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. So if:

alSourcei(source, AL_LOOPING, AL_FALSE);
alGetSourcei(source, AL_BUFFERS_PROCESSED, &count);
if(count > 0)
   alSourceUnqueueBuffers(source, 1, &buffer);

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.


So there is a bug in OpenAL Soft which could cause it to report processed
buffers that aren't marked processed yet, when the loop flag is toggled off.
But if possible, you shouldn't set the source as looping if you're going to
unqueue buffers from it.


> If it helps, our interface to OpenAL can be viewed at
> http://trac.wildfiregames.com/browser/ps/trunk/source/lib/res/sound/snd_mgr
>.cpp

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.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[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
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

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.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel