MacOS recording audio - chunking 4096 frames

Hi,

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?
Why initially submit the buffers if they are always returned empty?

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?

I'd like to know about such chunking, because IMHO the correct way to handle it would be
to advertise mmdevapi's a matching default recording period -- obviously not 10ms.
I believe the current mmdevapi code did not expect that behaviour and therefore does not
manage to fill as much frames as GetBufferSize would allow into a buffer.

I haven't checked smaller buffers. I'd like to avoid bombarding CoreAudio with 10ms buffer
requests of 480 frames each just because native mmdevapi advertises a 10ms period.

Thank you for your help,
 Jörg Höhle

[Ken Thomases]

On Jan 10, 2012, at 7:36 AM, [e-mail] 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