Intelligent default buffer sizes. about miniaudio HOT 3 CLOSED

Yep, the quality of the backend is something I'm planning on taking into account. A suitable approximate factor can be determined through testing.

Adjusting for specific hardware is something I'm already doing in ALSA (needed for Raspberry Pi), and I'm also planning on using that as one of the factors.

The calculation need not be perfect - it just needs to find a suitable balance between small enough that latency is not affected too badly and large enough that things don't become too sensitive to glitching (looking at you Raspberry Pi!). An application can always specify their own specific buffer size if they have unique requirements or would rather use their own logic for determining a suitable buffer size.

I've started testing a few ideas on my local branch which I'll be putting into the wild in the next version (coming as soon as I can!) so I can get a more accurate determination of it's usefulness. It can't be much worse than the current system...

from miniaudio.

Here my opinions:

1. Idea sounds very reasonable on paper but I'm not sure if it could work ok, there are really lots of hardware situations (plus audio libs backends) and choosing the best performance parameter is not easy... but, well, I think it worths at least trying.

2. That sounds good to me.

3. No alternative suggestion, just define a set of default sizes by hardware/audio-backend based on testing... I know, it's not a great solution...

4. Audio library backend. Maybe do the profiling on a second thread. Perform multiple times the same test on same hardware on different situations to make sure no external loads change results.

from miniaudio.

An initial implementation of this feature is in the dev branch and will be in the next version.

from miniaudio.