Improve handling of abnormal spec.samples values

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2020-05-14 15:37:54 +0000, Ethan Lee wrote:

XAudio2 has an incredibly peculiar behavior where it mixes samples in intervals of exactly 10ms, regardless of the mix format. Even for their "XAUDIO2_1024_QUANTUM" flag, the flag only works if you set the mastering voice sample rate to 48000 since, in reality, it just changes the interval from 10ms to 21.33 ms (no, seriously). As a result, when reimplementing XAudio2, you can end up with ridiculous quantum sizes like 480 and 441, which is actually handled pretty well in the most commonly-used backends (WASAPI, CoreAudio, Pulse) but is not handled everywhere. For FAudio, we've gotten reports of this being an issue for the dsp and emscripten backends:

FNA-XNA/FAudio#183

In theory the fix isn't too horrible, we just need to round to a nearby power-of-two when the backend doesn't support arbitrary quantum sizes, and the backing SDL_AudioStream should handle the rest.

Somewhat related: Pulse's method of calculating samples can lead to unintentionally tiny buffer sizes since it just halves the input value, so a 512-sample quantum will have a 256-sample window in reality (eep):

https://hg.libsdl.org/SDL/file/ed5f41281cb0/src/audio/pulseaudio/SDL_pulseaudio.c#l577

The doubling that happens later in the function makes sense, but is there a way to do this without shrinking the quantum size?