MacOS recording audio - chunking 4096 frames
ken at codeweavers.com
Wed Jan 11 19:43:54 CST 2012
On Jan 10, 2012, at 7:36 AM, Joerg-Cyril.Hoehle at 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.
More information about the wine-devel