Integrating FAudio, a reimplementation of XAudio2

[Ethan Lee]

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!

-Ethan

> On Oct 19, 2018, at 12:34 PM, Henri Verbeet <hverbeet at gmail.com> wrote:
> 
> On Fri, 19 Oct 2018 at 19:51, Henri Verbeet <hverbeet at gmail.com> wrote:
>> I think I missed a step there... why is copying the code into the Wine
>> tree a given? Does FNA not provide an API for external users?
> Actually, I read over that mail a little to quickly, and missed the
> second option, so ignore that reply.
> 
> Perhaps unsurprisingly, I'm in favour of having FNA be a proper
> library with a stable API that Wine can link against like everyone
> else.
>