Re: Problem with alSourceUnqueueBuffers

Hi,

> > What OpenAL device are you using, and which OS and soundcard?
> >
>
> OpenAL driver information...
> Vendor   : Creative Labs Inc.
> Renderer : Software
> Version  : 1.1

Can you output the actual name of the device being used, e.g.

printf("Device is %s\n", alcGetString(deviceHandle, ALC_DEVICE_SPECIFIER));

>From the above information, it could be the "Generic Hardware" or "Generic
Software" device.  Also, what version of the wrap_oal.dll do you have?

> > For the first iteration how many Buffers are you filling with the 2205
> > samples?
> >
>
> One buffer.
>
> > Are you using get playback offset to determine how many samples to
fill?
> > I would recommend using a fixed buffer size for the streaming
operations
> > rather than trying to compute how many samples have been played.   The
get
> > sample offset call is tricky to use because it returns an offset from
the
> > start of the buffer queue - not the offset in the current buffer.   So,
I
> > would use, say 4 x 25ms buffers and as and when a buffer is processed,
> > unqueue it, fill it with 25ms of audio data, and requeue it.
> >
>
> Yes, with alGetSourceiv( source, AL_SAMPLE_OFFSET, &samplePos ).

I think there is a fundamental difference in your method of streaming to
what I have typically seen.   Your method is relying more on get Sample
Offset than getting Buffers Processed as a way of determining when and how
many samples to requeue on the Source.

In the "buffer processed" method, you would need to queue more than one
buffer on the first iteration (e.g split the 2205 samples into 4 Buffers).
Then completely remove the get sample offset calls and simply wait for a
buffer to marked as processed.  At which time, you unqueue it, and fill it
with the same number of samples, and requeue it.

> If I recall
> correctly, the function returns the sample offset from the beginning of
> playback, which would include buffers processed, not just the buffers
> queued.

It is the sample offset from the beginning of the *current* queue. e.g If
sample offset returns say, 2000 samples, and then you unqueue a (processed)
buffer containing 1000 samples, and immediately ask for the sample offset,
it will be 1000 samples.   Are you taking this into account?

> Is there an issue with buffers if they are uploaded with different
> lengths of data?

There shouldn't be any issues ... but it may cost some memory reallocation,
that could otherwise be avoided by keeping the buffer the same size.

> > So if you keep generating, filling, and requeueing new Buffers the
Source
> > keeps playing without any problems?  Does it play without glitches?
Some
> > implementations of OpenAL enable a starved Source to automagically
restart
> > playing if the application never actually queries the playback state
and
> > just queues new buffers on it.
> >
>
> Yes, if I generate new buffers every iteration instead of trying to reuse
> processed buffers the source plays with zero problems, this is why I
don't
> think it is an underrun issue. On the other hand, I have put queries
before
> and after the calls to unqueue and queue and it reports that the source
is
> still playing.

So to be clear - the scenario that works is doing something like this ...

60 times per second ...

Get current Sample Offset
Compute samples played since last iteration
Gen a new buffer and fill it with that number of samples
Queue it on Source

Or are actually doing an unqueue operation and just ignoring the buffer
returned?

If you are not unqueuing then the sample offset returned each iteration
will always be greater or equal to the value you got on the previous
iteration.  As soon as you unqueue a buffer in an iteration, the next
iteration could see a lower sample offset value (quite likely given the 60
Hz update rate), which will cause issues as you won't queue any new data
for a longer period of time.

Dan
Creative Labs, UK



> --
> View this message in context: http://www.nabble.com/Problem-with-
> alSourceUnqueueBuffers-tp23845230p23856804.html
> Sent from the OpenAL - User mailing list archive at Nabble.com.
>
> _______________________________________________
> Openal mailing list
> Openal@...
> http://opensource.creative.com/mailman/listinfo/openal

> ForwardSourceID:NT0006CB12

_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal