[Openal] buffer size

Peter Mulholland darkmatter at freeuk.com
Thu Nov 9 03:07:33 PST 2006


Hello nic,

Thursday, November 9, 2006, 10:50:48 AM, you wrote:

> Hi Peter,

> Thanks for the info. I just tested and confirmed that you are correct,
> there is some undocumented 10ms granularity with Sleep(1); which was 
> definately contributing to my problems!

It is not undocumented. It is documented under information about
timers, "Win32 and COM development->System Services->SDK
Documentation->Windows System Information->Time->About Time->Windows
Time."

No kernel has a granularity of 1ms.

> I increased the buffer to 100ms as you suggested and the performance is
> good, however when I drag the window around the screen the CPU time 
> often goes to 100% during dragging, and if it remains there for more 
> than 100ms the buffer is exhausted and playback stops.

Do you have the setting that shows a window's full contents while
dragging turned on? If so, that's probably why. I don't think MS ever
thought about this one from a performance point of view - the blit
will be accelerated, but I can bet it also causes buttloads of
WM_PAINT messages to be sent to the application.

> The CPU time seems to go to 100% when dragging any window (not just my
> application or anything to do with OpenAL). Is this normal behaviour for
> windows? Does anybody know a technique to maintain the OpenAL buffer in
> this circumstance?

Use a thread to fill the buffer. The thread will never be blocked by
your application's message loop. It might be an idea to run the audio
thread at a slightly higher priority.

-- 
Best regards,
 Peter                            mailto:darkmatter at freeuk.com



More information about the Openal mailing list