Re: OpenAL for voicechat

Daniel PEACOCK <[email protected]>
Newsgroups gmane.comp.lib.openal
Message-ID <OF96C38475.1B829E7D-ON802576B7.005D7A64-802576B7.005EC6D5@cli.creaf.com>



Forgot to ask last time ... what OpenAL implementation and OS are you
using?

> 1) If I would use a while() than the I would fill all buffers (4)
> with the same 40ms recorded stream.

You need to modify the inner part of the while loop so that each buffer
gets the next 40ms of received audio.

The problem is, especially with short buffers like yours, that alGetSourcei
AL_BUFFERS_PROCESSED could very easily return more than 1 buffer as being
processed.  I'm not sure how often you are calling the code below, but I
would recommend adding some OutputDebugStrings to monitor 'processed'.
Anytime more than 1 buffer is processed and you only unqueue, fill, and
requeue 1 buffer the source queue has become shorter and is more likely to
run out of data.

Also, are you filling all 4 buffers before calling alSourcePlay?  i.e. are
you waiting for 4 x 40ms of audio to be recieved from the network before
playing anything?  If you don't do that you are again going to run into
underrun issues.

Can you also add an OutputDebugString message when you detect that the
Source has stopped playing?

> It sounds like OpenAL doesn't mix the two sources but plays the
> received packets after each other.

Hmmm ... you are creating one OpenAL device and context, and two separate
Sources with two sets of 4 Buffers right?  Mixing multiple sources is
fundamental to OpenAL so I'm sure that is not broken.

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 79 Knightsbridge, London SW1X 7RB


[email protected] wrote on 01/26/2010 04:50:59 PM:

> Thanks for your fast answers!
>
> 1) If I would use a while() than the I would fill all buffers (4)
> with the same 40ms recorded stream.
> I'm filling a free buffer everytime I receive a packet. So this part
> is called everytime I receive a packet and fills one free buffer of
> the correct source:
>
> //Code:
> ALint processed, state;
> alGetSourcei(soundsOut_current->source, AL_SOURCE_STATE, &state);
> alGetSourcei(soundsOut_current->source, AL_BUFFERS_PROCESSED,
> &processed);
>
> if(processed > 0) //If there is a free buffer
> {
>    ALuint buffer;
>    alSourceUnqueueBuffers(soundsOut_current->source, 1, &buffer);
>     //Fill the buffer with the received data
>     alBufferData(buffer, AL_FORMAT_MONO16, decoded_buffer,
>  voice_Bufsize, voice_SamplesPerSecond);
>          alSourceQueueBuffers(soundsOut_current->source, 1, &buffer);
> }
> // Restart in case we didn't get more data in time
> if(state != AL_PLAYING) alSourcePlay(soundsOut_current->source);
> //-------------------------------------------------------------------
>
> 2) Buffersize is 1280 Byte and samplerate is 16000 Samples/s.
>
> 3) No it doesn't!
>
> It sounds like OpenAL doesn't mix the two sources but plays the
> received packets after each other.
>
> Best regards,
> Peter Soxberger
>
> --
> Nur noch bis 31.01.2010: DSL-Komplettpaket für 16,99 Euro/mtl.!*
> http://portal.gmx.net/de/go/dsl02
>
> --
> Nur noch bis 31.01.2010: DSL-Komplettpaket für 16,99 Euro/mtl.!*
> http://portal.gmx.net/de/go/dsl02
> _______________________________________________
> Openal mailing list
> [email protected]
> http://opensource.creative.com/mailman/listinfo/openal

> ForwardSourceID:NT00079442


_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.