WinMMAudioRender hangs with UMC_ERR_NOT_ENOUGH_BUFFER

WinMMAudioRender hangs with UMC_ERR_NOT_ENOUGH_BUFFER

Have WinXP SP2 VS2005 MDI application that uses WinMMAudioRender. Each child window has its own player control thread and video render thread and audio render thread. Works great with one child window. And works great with two child windows, with audio from the separate streams mixed. But audio renderer hangs pretty quickly with three child windows. The three video renderers keep soldiering on, but the audio renderers are hung, all stuck with UMC_ERR_NOT_ENOUGH_BUFFER when calling LockInputBuffer.

Before I begin debugging the IPP UMC audio renderer, has anyone else seen this? Anyone else implement an MDI application using the IPP UMC audio renderers?

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

One more point: I strongly suspect the perpetual UMC_ERR_NOT_ENOUGH_BUFFER is triggered by an underrun condition, i.e., the audio processing thread fails to deliver data to the audio renderer as quickly as the audio renderer demands the data. Perhaps the audio renderer loses track of buffers that become available but are unused because of the underrun condition.

In addition to observing this problem in an MDI environment, I've also seen it with only one child running with a debug compile and verbose TRACE messages spewing into the output pane. Once again, underrun appears to be the trigger.

winmm_render.cpp has method "Release" that calls "waveOutUnprepareHeader". Everything works great until for some reason "waveOutUnprepareHeader" fails to return. This in turn fails to call "ReleaseSemaphore" and the audio rendering stops. Don't know yet why "waveOutUnprepareHeader" hangs.

Will submit this to tomorrow.

Thanks for reporting that


Leave a Comment

Please sign in to add a comment. Not a member? Join today