Actual buffer size depends on sample rate (macOS)

[jmyhrman]

This problem is specific to the CoreAudio backend on macOS.

The actual buffer size differs from requested buffer depending on requested sample rate.

Using the built-in sound card on an MBP, the requested buffer size X is only observed as the actual buffer size Y in the callbacks when running at SR 44.1kHz. When requesting other sample rates, the relation seems to be that observed buffer size, Y appears as Y = ceil(X*SR/44.1).

For example, requesting X=64, SR=48000 yields Y=70.

In other words, the observed behaviour is almost as if the requested buffer size is in the native sample rate domain rather than in the domain of the requested sample rate.

The expected result would be that the requested buffer size is also in the domain of the requested sample rate.

In the test, I have both input- and output streams running with the same requested configuration.

Env: MBP 14.3 (2017), macOS 11.0.1

[mitchmindtree]

Interesting find, thanks a lot for sharing.

Is it possible that this is due to the order in which buffer size and sample rate are requested? E.g. I wonder if the audio unit's buffer size is set prior to when the sample rate is set, and when the sample rate is set the buffer size is updated accordingly? Would be interesting to see what e.g. portaudio are doing here.

[jmyhrman]

Could be the case. My plan was the same, to look into other rather mature frameworks such as JUCE and see what the exact order of operations is there, and to better understand the problem.