WASAPI capture buffer size

Question

I am using WASAPI in wp8.As I use Getbuffermethod in shared mode each time it returns buffers with different size.I am capturing in 8000Hz/16bit and sometimes Getbuffer returns buffer with 80 samples and sometimes with 400 samples and .Is this a normal behaviour while sending different hnsBufferDuration to IAudioClient::Initialize doesn't have any effect in the buffer size?

Answer 1

Yes, this is normal behavior. I don't know about windows phone specifically but at least on windows desktop this is the way shared-mode capturing is supposed to work so I suspect it's not different on wp8. When dealing with WASAPI capture buffers there's 3 things you should be aware of.

• The total size of the buffer which is specified as hnsBufferDuration in IAudioClient::Initialize. WASAPI will create a buffer of the requested size OR LARGER. Call IAudioClient::GetBufferSize to get the actual total buffer size.

• The periodicity (also an argument to IAudioClient::Initialize). This parameter specifies how often WASAPI will process the buffer, for example, you may set up a 30 ms buffer which is processed every 3 ms by WASAPI. The periodicity is only used in exclusive mode.

• The packet size, this is what you're dealing with. What happens is that the size of the internal WASAPI buffer doesn't actually change (that's the one reported by GetBufferSize), it is just processed in small parts of varying size.

If you want to know in advance how large the next block will be, call IAudioCaptureClient::GetNextPacketSize (only works in shared mode). If all you want to do is pre-allocate your own buffers so you don't have to reallocate on each call to GetBuffer, you can just set up your own buffer which is equal in size to IAudioClient::GetBufferSize.

Answer 2

As documented on MSDN:

The IAudioClient::Initialize method allocates the buffer. The client specifies the buffer length in the hnsBufferDuration parameter value that it passes to the Initialize method. [...]

For capture clients, the buffer length determines the maximum amount of capture data that the audio engine can read from the endpoint buffer during a single processing pass. The client should always call GetBufferSize after calling Initialize to determine the actual size of the allocated buffer, which might differ from the requested size.

The API implements it in a way making sense for the capture layer and targets minimal API overhead. It does not accumulate data internally for no reason. If you need fixed size buffers, you are free to pile the data up on the buffer you manage.