On Jan 10, 2012, at 7:36 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
looking at mmdevapi/tests/capture logs, I found 2 issues
1. the 5 buffers initially sent are all returned with 0 bytes So I added a loop to return empty buffers to the audio input queue, such that GetBuffer returns data when GetCurrentPadding shows it.
But why were these buffers returned at all?
Don't know off-hand. I haven't looked, but could we be calling AudioQueuePrime() for the capture case? We shouldn't be and who knows what it does. Alternatively, are we calling AudioQueueFlush() or AudioQueueStop() after enqueuing the buffers?
2. Using a ~500ms mmdevapi duration, Wine gave MacOS CoreAudio 5 buffers of ~4399 frames each. However, MacOS solely returned 4096 frames.
Is anybody aware of such chunking?
Again, not off-hand, but it doesn't surprise me that it would have an internal buffer size and prefer to return whole buffers. See, for example, the device property kAudioDevicePropertyBufferFrameSize. Regards, Ken