Re: Looping and buffer queuing

Hi Carsten,

For general streaming with buffer queuing you don't want to enable Source
Looping.  The behaviour you reported as seeing (no Buffers being processed)
is correct.   The Source will keep playing the entire buffer queue - e.g If
you have Buffers ID's 1,2,3, & 4 in the queue, and play with looping
enabled, you will hear 1,2,3,4,1,2,3,4,1,2...    Each Buffer is always
'pending' playback so will never be marked as 'processed',

Assuming you are using a buffer queue to stream a (long) piece of audio you
should know if you have finished transferring all the audio from the stream
to the Buffer Queue.  So perhaps something like this will work.

// At regular intervals / part of a game loop etc ... do something like
this for each Source with a Buffer Queue ...

bAddedNewAudio = AL_FALSE

iProcessed = Get Buffers Processed on Source
if (iProcessed != 0)
{
	// m_iSourceQueuedCount is a per-Source variable that tracks the
number of buffers that have been queued
	// Be sure to set it to the appropriate number in the code that
starts playback of the Source, e.g. if you queue 4 buffers at play time,
set m_iSourceQueuedCount to 4.
	if (iProcessed == m_iSourceQueuedCount)
	{
		// The Source has played all the Buffers in it's queue
		Stop Source	// Not strictly necessary - but works around a bug
on some implementations
	}

	while (iProcessed)
	{
		uiBufferID = Unqueue a buffer
		m_iSourceQueuedCount --
		if (FillBufferWithMoreAudioIfAvailable(uiBufferID))
		{
			// More audio data was found ...
			Queue uiBufferID on the Source
			m_iSourceQueuedCount ++
			bAddedNewAudio = AL_TRUE
		}
		iProcessed--;
	}

	iState = Get Source State
	if (iState != AL_PLAYING)
	{
		if (bAddedNewAudio)
		{
			// This Source should be playing - it must have stopped
prematurely, re-start it
			Source Play
		}
		else
		{
			// This Source finished naturally
			Release Source back to available Source pool etc ...
		}
	}
}

Dan
Creative Labs (UK) Ltd.

Notice
The information in this message is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to this
message by anyone else is unauthorized.  If you are not the intended
recipient,  any disclosure,  copying or distribution of the message,  or
any action taken by you in reliance on it,  is prohibited and may be
unlawful.  If you have received this message in error,  please delete it
and contact the sender immediately.  Thank you.

Creative Labs UK Ltd company number 2658256 registered in England and Wales
at 79 Knightsbridge, London SW1X 7RB



                                                                           
             Carsten Fuchs                                                 
             <CarstenFuchs@T-O                                             
             nline.de>                                                  To 
             Sent by:                  [email protected]      
             openal-bounces@op                                          cc 
             ensource.creative                                             
             .com                                                  Subject 
                                       [Openal] Looping and buffer queuing 
                                                                           
             07/06/2010 13:04                                              
                                                                           
                                                                           
                                                                           
                                                                           




Dear OpenAL list,

I'm currently trying to find a good solution for the "worst" case with
buffer queuing, where all
buffers are processed before the application had a chance to enqueue more
buffers.

The "normal" behaviour in this case is that the source enters state
AL_STOPPED, and it can be
difficult to learn later whether this state was entered as a result of all
buffers were
processed or from an explicit call to alSourceStop().
(One solution might be to duplicate and keep the source state ourselves,
but that comes with
it's own set of problems, e.g. think of non-queued buffers that are
assigned with alSourcei().)

When I found in the OpenAL 1.1 spec that

"AL_LOOPING is a flag that indicates that the source will not be in
AL_STOPPED state once it
reaches the end of last buffer in the buffer queue."

I thought it might be a good idea to combine AL_LOOPING with buffer
queueing in order to avoid
the problematic buffer "underrun" as outlined above.


Well, I found that if AL_LOOPING is activated, the query for
AL_BUFFERS_PROCESSED always returns
0 (tested with both the Windows SDK as well as with OpenAL-Soft on Linux).
That is, in order to "circumvent" this, on each OpenAL "update" in the
"master game loop", we
have to disable looping first, then query for the number of buffers
processed, possibly re-queue
more/reused buffers, then enable looping again.

At the same time, although the observed behaviour (buffers_processed==0
while looping==true)
seems correct, the spec says nothing else about the behaviour of the buffer
queue while looping
is enabled. For example, my first assumption was that when you have five
buffers enqueued and
looping is enabled, the first four will be processed and reportet as usual,
and looping only
occurs over the fifth buffer.


Considering all this, is this combining of looping with buffer queuing
generally a recommended
and practiced idea (when the main goal is to avoid accidentally entering
the AL_STOPPED state)?
Anything else we should take into account? Additional or alternative
considerations?

I'd be very grateful for thoughts/feedback.  :-)

Best regards,
Carsten



--
    Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
           Learn more at http://www.cafu.de

_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal

ForwardSourceID:NT0007DBBE

_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal