360 samples is very small for a Buffer, especially if you are playing at
44.1KHz, as that means the Buffers are only about 8 milliseconds in
duration. Even if your application is updating the Buffers at 60Hz, the
OpenAL implementation is quite likely to be performing mixing in a separate
thread that is called less often (more likely 25 times per second). So
this would definitely create a scenario where Buffers Processed returns 0
for a while, and then suddenly returns 2 or 3. That might be OK - as long
as you have more than 3 Buffers in the queue, and that you immediately
unqueue, fill, and requeue all of the buffers (otherwise you will starve
the Source of audio data).
The Creative Windows OpenAL SDK includes some example code for streaming
that might be worth looking at.
In general, you will have to have a reasonable amount of data in the
Source's Buffer Queue (e.g. at least 100ms if this application is intended
to run on many OpenAL implementations on many PCs). This should be split
into multiple Buffers (e.g 4 Buffers of 25ms each). When ever you request
the numbers of Buffers processed, you should unqueue all of them and
requeue them with new audio data. You should also include code that
checks that the Source is still playing, and if not, include logic to start
it playing again.
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 Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB
qartar
<
qartar@...>
Sent by: To
openal-bounces@op
openal@...
ensource.creative cc
.com
Subject
Re: [Openal] Problem with
06/03/2009 10:32 alSourceUnqueueBuffers
AM
Luis-33 wrote:
>
> Hi qartar. First of all, how big are your buffers? They might be too
> small.
> Also, from what I see, you are only unqueuing a single buffer per
> iteration,
> even if count is indicating more than one buffer processed. You should
> unqueue and refill every processed buffer in each loop iteration, else
> your
> source is going to run out of audio data quickly. Hope that helps :)
> By the way, is there any reason not to be using buffers in a circular
way?
>
> Cheers!
>
Thank you for your reply. The buffers are fairly small since they are
updated around 60 hz, so approximately 360ish samples per iteration, but I
never saw any documentation referring to minimum buffer sizes so I am a
little confused. (It may be worth to mention again that no errors are being
generated). The function determines how many samples to fill per iteration
by checking the current source sample offset against a mixahead value so
even if there are extra processed buffers the source does not underrun. As
far as circular buffers go, since I haven't seen a way to update a buffer
while it is playing (a la DirectSound) I thought this would be close. If
you
have better solution I would be very interested.
--
View this message in context:
http://www.nabble.com/Problem-with-alSourceUnqueueBuffers-tp23845230p23848351.htmlSent from the OpenAL - User mailing list archive at Nabble.com.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openalForwardSourceID:NT0006CABE
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal