[Openal] two questions
Daniel PEACOCK
dpeacock at creativelabs.com
Wed Mar 25 03:12:45 PDT 2009
Hi Angelo,
Some AL implementations will immediately act upon a "play" call (i.e you
can hear audio from the buffer in ~1 millisecond). Other implementations
will defer play calls to the next service update thread. In the second
case, it will be a random amount of time before you hear audio from the
buffer, ranging from immediately, to slightly less than the update rate of
the service routine (on the "Generic Software" device this is every 25ms).
Generally in order to prevent the audio breaking up we recommend developers
to queue at least 100 milliseconds of audio on a Source. You can get away
with less in some situations - especially on hardware - but if you want
something that works everywhere then 100ms is probably a reasonably safe
bet.
In order to know the duration of the audio you are putting in the buffers
it is necessary to know the playback sample rate. e.g 2048 samples @
48000Hz is 43ms but 2048 samples @ 8000Hz is 256ms.
To track down the source of the audio glitch I would write all the audio
data that you put in AL Buffers to a single file. The "Capture" example
code in the AL SDK shows how you can write a wave file to disc from a
stream of audio (in that case the audio is what has been captured but it
could be adapted to use any audio data). The only gotcha is to remember to
'fix' the file by storing all the appropriate lengths in the Wave header
after you have finished writting audio data.
You should, of course, be checking for things like OpenAL running out of
data (in which case the source state will become stopped and will need to
be restarted - which will cause a gap in the audio - and quite possibly a
glitch).
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
angelo
<angelo70 at gmail.c
om> To
Sent by: "openal at opensource.creative.com"
openal-bounces at op <openal at opensource.creative.com>
ensource.creative cc
.com
Subject
[Openal] two questions
03/25/2009 07:38
AM
Hi All,
i am working on a simple application, an half.duplex streaming with a
remote embedded device.
While receiving audio on the pc side, i was wondering if there is a
fixed total amount limit (samples) of audio to be stored in the AL
buffers before start to play ?
If i have 4096 bytes (16 bit mono, 2048 samples) the stream is played
fine, but if i start to play with a received amount of 2048(1024
samples), i hear a bounce, since the first part is consumed by the
player and there are not other samples ready for a while.
Also, starting to play, i hear a little glitch, like a "blup". It is
probably due to the first chunks of samples received that contain some
noise. Is there a wai to detect if is an AL problem or if the "blup" is
in the samples received ?
many thanks,
Angelo
_______________________________________________
Openal mailing list
Openal at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal
ForwardSourceID:NT0006A8E2
More information about the Openal
mailing list