[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