[Openal] xfi issues
Daniel PEACOCK
dpeacock at creativelabs.com
Tue Aug 28 17:41:30 PDT 2007
Hi Xavier,
queue
Thanks again for the report. The native X-Fi OpenAL device sets a Source's
state to AL_INITIAL whenever the Source has no buffers attached (or
queued). This is why you are see a difference between unqueuing
everything first or unqueuing & requeuing one a time. The later case does
not result in a time when the Source has 0 buffers attached and the state
changes from AL_STOPPED to AL_INITIAL.
Dan
Creative Labs, Inc.
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.
Xavier Bouchoux
<xavier at nadeo.com
> To
Sent by: openal at opensource.creative.com
openal-bounces at op cc
ensource.creative
.com Subject
Re: [Openal] xfi issues
08/28/2007 06:50
AM
Xavier Bouchoux a écrit :
> hello,
> [...]
>
> And I seem to have related issues with streamming sounds. I'll
> investigate a bit further.
So the issue I have is that a source incorrectly (I think!) changes state:
- create a source
- queue some buffer
- play the source
- wait until the sources eats all its buffer
(at this point the source is AL_STOPPED)
- dequeue all the buffers
the sources changes to AL_INITIAL with the X-fi driver. (with the
software it stays "AL_STOPPED".)
I'd says by reading the spec that that the correct behaviour would be to
stay AL_STOPPED.
Additionally, If you don't empty the queue but replace the processed
buffers by fresh ones, one by one, it stays "stopped".
That is, if when the source has processed all its buffers,
you dequeue all and requeue all -> it will be in AL_INITIAL state,
whereas if
you dequeue and requeue the buffers one by one, -> AL_STOPPED
At the end of the mail is a patch for PlayStream.cpp that shows the
problem.
(To be honest both issues are minor for me:
the buffer changing name only bothered me because it triggered an assert
in my code,
and this streamming issue only revealed a bug in my code, I was
refilling the buffer queue twice after a starvation...)
xavier.
@@ -104,6 +104,23 @@
iTotalBuffersProcessed = 0;
+ Sleep(3000); // starve the source.
+
+ alGetSourcei(uiSource, AL_SOURCE_STATE, &iState);
+ ALFWprintf("State before = 0x%x\n", iState);
+
+ iBuffersProcessed = 0;
+ alGetSourcei(uiSource, AL_BUFFERS_PROCESSED, &iBuffersProcessed);
+ ALFWprintf("processed buffers = 0x%x\n", iBuffersProcessed);
+ while (iBuffersProcessed>0) {
+ alSourceUnqueueBuffers(uiSource, 1, &uiBuffer);
+ iBuffersProcessed--;
+ }
+ // at this point, all the buffers are unqueued
+
+ alGetSourcei(uiSource, AL_SOURCE_STATE, &iState);
+ ALFWprintf("State after = 0x%x\n", iState);
+
while (!ALFWKeyPress())
{
Sleep( SERVICE_UPDATE_PERIOD );
_______________________________________________
Openal mailing list
Openal at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal
ForwardSourceID:NT00045EE2
More information about the Openal
mailing list