Integrating FAudio, a reimplementation of XAudio2

[Henri Verbeet]

On Fri, 19 Oct 2018 at 20:12, Ethan Lee <flibitijibibo at flibitijibibo.com> wrote:
>
> Ideally that’d be the goal, unfortunately there’s some friction that XAudio2 throws at us.
>
> In the 100% ideal situation we could link to a native FAudio, but the main thing that blocks it is how XAudio2 (and XACT) expose memory to applications. There are a handful of calls that throw memory at you that you’re expected to free with CoTaskMemFree, which a native FAudio would not be able to line up with, so you would have to duplicate the data structure in the XAudio2 built-in and then free it… but then the `free` implementation can vary (by default it’s SDL_free), so you’d have to be sync’d with FAudio at the source level anyhow.
>
> That said, I was thinking about it again this morning (we’ve been throwing around ideas for a couple days) and realized that even XAudio doesn’t _necessarily_ ask for CoTaskMemFree, it asks for “XAPOFree” for example, which macros to either CoTaskMemFree or XMemFree. So a possible fix on my end could be to expose FAudio_malloc/FAudio_free as exported functions (not just internal macros, which is how it works now), and then projects like Wine can call FAudio_free after duplicating the memory. It’s still a duplication,  and accuracywise it’s not entirely the same as the official macro, but it sounds like that’d be preferred to statically linking the whole implementation!
>
The way you typically solve that kind of thing is by passing an "ops"
structure with callbacks for e.g. memory allocation, thread creation,
etc. on library initialisation, which the library then uses
internally.