https://bugs.winehq.org/show_bug.cgi?id=46725
--- Comment #13 from Ethan Lee flibitijibibo@gmail.com --- That all sounds correct - where things get complicated is WASAPI shared mode's method of calculating the buffer size. It's actually a lot like XAudio2 itself where the sound server is running at a specific frequency, and then when you open the mastering voice with another frequency, it has to calculate the frames needed to fit the server's quantum size.
So, as an example, consider a server running at 48KHz. If the mastering voice is at 48KHz, it'll just be 480, a nice even number that makes complete sense:
48000 samples per second / 100 updates per second = 480 samples per block (SPB)
480 SPB * 48000 (server) / 48000 (master) = Still 480
However, if the master is at 44.1KHz, it gets weird:
480 SPB * 48000 (server) / 44100 (master) = ~522...
... but then WASAPI returns 528...? Maybe SIMD alignment or something? We use the full space in FAudio and it sounds okay, maybe they cheat and resample it just a teeny bit more than the application knows to keep all the memory aligned.
Point being, we need a little bit more information from the OS before this can be truly solved in FAudio. Here's the SDL issue I've been using to log my Audio API Mental Breakdown(TM):
https://bugzilla.libsdl.org/show_bug.cgi?id=4181
If the above SDL issue got fixed, this would be really easy to resolve on FAudio's end.