@VaL-Doroshchuk
Hi!
"big buffer" is quite relative and that "big" depends on needs.
In my case I'm using audio data to pitch recognition and depending on pitch range to recognize, I'm using 512, 1024 or 2048 samples buffer, so it is apparently 11, 23 and 45ms (more less). Those power-of-two buffer sizes are required by FFT routines.
But my app is flexible enough, and when underlaying OS is not capable to keep that buffer size it will portion any audio data size as needed for pitch detection algorithm.
(on Android Qt Audio is used and with low level device a delay between data ready call could sometimes be about 100ms)
However smaller buffer gives faster app response (displaying pitch in score).
And no any glitches was notices even if buffer is set to 64 frames (2ms)
And if we take simpler example, which could be passing input mike data to an output device - more quicker we send incoming data to the out - less delay will be in speakers - it means less buffer - faster response.
