On Jan 10, 2012, at 7:36 AM, Joerg-Cyril.Hoehle@t-systems.com wrote:
looking at mmdevapi/tests/capture logs, I found 2 issues
- 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?
- 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