Re: OpenAl for streaming

Yes, you can call alSourceUnqueueBuffers while a source is playing,
presumably if there is a processed buffer available to unqueue which
you seem to be doing.

First, make sure you cleared alGetError() before your AL call in
question to make sure something else didn't set that condition first.
AL_INVALID_ERROR could have been set elsewhere and you are just
noticing it here.

Assuming that you are correct about alSourceUnqueueBuffers returning
an error, you might have found a bug. I filed a bug a couple of years
ago on the Mac which sounds similar to your problem. The
implementation was occasionally returning the wrong buffer id so if I
tried to unqueue that returned id number, something would fail. They
have since fixed that bug, but maybe iOS inherited the problem but not
the fix. But I have not experienced this problem on iOS thus far.

Reference Bug ID: 6512633

The workaround which I employed is I maintain my own queues of buffer
ids. In principle, the buffer ids are always going to be returned in
the order they were submitted for each source so you know what the ID
is supposed to be when you unqueue them. Thus I know which buffers are
available to be recycled without depending on the function to return
me a value. This has worked for me without any hitches. But this
presumes that your error is simply that the returned buffer IDs are
wrong.

-Eric


On 7/28/10, Susmith M R (RBEI/ECF1) <[email protected]> wrote:
> Thanks for your reply
> I am not using alBufferDataStatic. My problem is, when I use
> alSourceUnqueueBuffers, I am getting the same Unqueued bufferid again. Why
> it is happening? This changes the state of my program.
>
> One more question.
> Can I use alSourceUnqueueBuffers while some buffer is playing. When I used
> like this sometimes I am getting AL_INVALID_VALUE. Why is this? How do we
> know the buffer id of the processed buffers?
> I am using
>                         alGetSourcei( m_nALOalSource, AL_BUFFERS_PROCESSED,
> &iBuffersProcessed );
> To get the no of buffers processed and using the following loop to unqueue
>                        while ( iBuffersProcessed )
>                         {
>                             uiBuffer = 0;
>                             alSourceUnqueueBuffers( m_nALOalSource, 1,
> &uiBuffer );
>
> bCheckPrintALErrorString("alSourceUnqueueBuffers")
>                             iBuffersProcessed--;
>                         }
> I am not sure why alSourceUnqueueBuffers is returing AL_INVALID_VALUE. In
> the document it is specified that alSourceUnqueueBuffers will only return
> AL_INVALID_VALUE when "At least one buffer can not be unqueued because it
> has not been processed yet.". From the above code how is that possible since
> I am only unqueueing iBuffersProcessed from the processed queue.
>
>
> Best Regards
>  Susmith MR
>
> -----Original Message-----
> From: Eric Wing [mailto:[email protected]]
> Sent: Wednesday, 28. July 2010 12:20 PM
> To: Susmith M R (RBEI/ECF1)
> Cc: [email protected]
> Subject: Re: [Openal] OpenAl for streaming
>
> On 7/27/10, Susmith M R (RBEI/ECF1) <[email protected]> wrote:
>> Hi everyone,
>>
>> I am developing an OpenAL based application for iPhone.
>>
>> When I use alSourceUnqueueBuffers in a loop I get the same unqueued
>> BufferID
>> for the immediately-next alSourceUnqueueBuffers command. Since I am using
>> a
>> bufferID list to reuse the bufferIDs for my application, there is no need
>> to
>> recreate or delete the buffers. I have already created a set of buffers
>> during the initialization of my application. After unqueuing the buffer
>> from
>> the OpenAl queue I use the unqueued bufferIDs to fill new buffer data
>> using
>> albufferdata and then queue it to OpenAL. I don't know when exactly the
>> buffer will be freed. Please refer
>> http://old.nabble.com/Why-does-alDeleteBuffers-gives-a-AL_INVALID_OPERATION-error--td22632832.html.
>> Can this result in any internal conflict in OpenAL state? alBufferData and
>> alSourceQueueBuffer are not returning any error.
>>
>> Is there any way to know the completion of the command
>> alSourceUnqueueBuffers?
>>
>
> Reusing the buffer is fine. I think of it like malloc and free. You
> use malloc to allocate a block of memory. You write over and over
> again to that same block of memory for reuse. But when you are finally
> done, you need to free that block of memory.
>
> If you stick to standard OpenAL, I don't think you need to expect
> alSourceUnqueueBuffers to have a race condition unless Apple has a
> bug, in which case you should file a bug report. However, if you are
> using the iPhone OpenAL extension, alBufferDataStatic, then you have
> to worry about alDeleteBuffers failing. It is not just limited to
> alSourceUnqueueBuffers either. alDeleteBuffers will be your pinch
> point. You will need to call alDeleteBuffers and check alGetError() to
> see if it failed (because Apple overloaded the function for this
> case). Then you must react accordingly (after the fact) if there is a
> failure.
>
> Or you could avoid using the alBufferDataStatic extension.
>
>
> I highly recommend my book, "Beginning iPhone Games Development" in
> which I extensively cover OpenAL. Coincidentally, the longest chapter
> in the book is on audio streaming and there is a full blown OpenAL
> implementation that includes streaming. I also spend considerable
> energy explaining the sharp knives associated with the
> alBufferDataStatic extension on iOS. (The Creative/Xbox implementation
> which also offers the extension is apparently immune to these
> problems.)
>
> http://playcontrol.net/iphonegamebook/
>
> -Eric
>
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal