OpenAL Streaming (Queue Buffers)

Simon Burchert · 2010-08-16T10:31:01

I have written some code that plays an ogg vorbis file with OpenAL.My code opens the ogg-file and reads from it whenever a buffer is to be filled.As a "simple" loop would cost me 100% CPU, I have to sleep a little bit somewhere.So I set up 4 buffers which will be queued and played one after the other.After one processed buffer is filled again and queued on the source, I sleep as long as 1 buffer should need to be played. That is (float)PCM_PER_BUFFER/44100*1000 ms.But it can still happen that the stream stops playing (e.g. when computer is busy I think), which means that all 4 queued buffers were played before new buffers are filled and queued.But how can that be? I can't imagine that some of my code in the thread takes as long as 3 or 4 buffers.Does anybody has a tip how I might solve that problem? Is it possible to use callbacks that OpenAL automatically calls as a buffer on a source was processed?My code looks about like that (pseudo-code):while(playing){ n = getProcessedBuffers(); // should be 0, 1 or maybe 2. Never 3 or 4... while(n--) // while there are processed buffers to fill { // unqueue processed buffer alSourceUnqueueBuffers(Source, 1, &b); cur = getCurrentBuffer(); // buffer num (0-3) to fill fillBuffer(Buffer[cur]); alSourceQueueBuffers(Source, 1, &(Buffer[cur])); } sleep(sleepTime);}

Engines and Middleware Programming

Started by Tenry August 14, 2010 03:42 PM

11 comments, last by KulSeran 13 years, 8 months ago

Tenry

187

Author

August 16, 2010 09:21 AM

Okay, I changed sleep time from 92ms to 20ms, and I don't notice any more CPU usage (program uses 0-3% CPU). I listened to a stream for many minutes and there seemed to be no interrupt.

Maybe that's really the solution now :)

Ron AF Greve

900

August 16, 2010 10:01 AM

I had the same problem. When the buffers are depleted it stopped. I solved it by remembering what state it should be in then querying OpenAL for the state it is in. When it should be playing but isn't I just call alSourcePlay again:

		if( Stop && BufferQueue.empty() )		{			InfoLog << "Stopping  sound because we reached end of file" << endl;			alSourceStop( Sources[ 0 ] );			State = eStopped;			Reset();		}		else		{			ALenum ALState = 0;        			alGetSourcei( Sources[ 0 ], AL_SOURCE_STATE, &ALState);       			if( ALState != AL_PLAYING)			{				InfoLog << "Starting  sound (or resuming sound because we ran out of buffers)" << endl;				alSourcePlay( Sources[ 0 ] );				}		}

Ron AF Greve

KulSeran

3,272

August 16, 2010 10:31 AM

Quote:
Original post by coyote-development
Quote:Original post by KulSeran
There is a really good chance that you are going to miss your window (windows is granular on sleeps with about 15ms of jitter).

What do you mean by that? What does a thread in the background have to do with a window?

I assumed you were working on Windows(tm) the operating system. Linux has similar issues with sleep, but the scheduler is different and so the jitter is different (and I don't recall the average skew on a sleep). On Windows(tm), sleeps tend to skew to the next multiple of 15ms. So, by sleeping for too much time, there is a good chance your app "misses" the opportunity to update the buffers.

My Blog

OpenAL Streaming (Queue Buffers)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

OpenAL Streaming (Queue Buffers)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines