Core Audio (WASAPI) buffer event timing

Question

I'm using the Windows core audio functions, mostly WASAPI, to render an exclusive stream, following the example in Exclusive-Mode Streams.

This creates two alternating buffers played and filled alternately. There is an event tied to buffer completion that wakes the thread so it can refill the buffer just completed. GETPOSITION shows that the thread is waked when the current buffer is at frame 147 of a 160 frame buffer. This leaves me with 13/160 of a buffer time to get a new buffer, fill it, and release it. I have a lot of calculation to do, this isn't enough time. I suppose I could keep control of the processor instead of sleeping when a buffer is filled, but that doesn't seem like the right solution.

Further, even though my process is "PRO AUDIO" and has a priority of 25, sometimes the buffer completion event is delayed still farther, so the system starts replaying an unfilled buffer. I haven't found any discussion of how this timing is supposed to work, or how it can be controlled. I expected the buffer completion event to arrive within a small number of frames into the next buffer. Is anyone familiar with this stuff? Either with a solution or a clue about where to look for one?

Answer 1

You should have two threads. In the main thread, you do all your audio processing and calculations, and deliver the results to the secondary thread. The secondary thread's job is solely to wait for WASAPI events and write the products of the main thread out to the sound card. The thread which writes audio out should be doing no audio processing.

Answer 2

It appears you have the share mode set to shared not exclusive, in exclusive mode you get two buffers of the same size when one buffer is finished the event is signalled and the second buffer of the same size is returned

However if you have the share mode set to shared you are only given one buffer the help page IAudioClient::GetDevicePeriod method explains this.