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