WinMMAudioRender hangs with UMC_ERR_NOT_ENOUGH_BUFFER

[franknatoli]

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?

[franknatoli]

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.

[franknatoli]

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 premier.intel.com tomorrow.

[Vladimir_Dudnik]

Thanks for reporting that

Vladimir