Integrating FAudio, a reimplementation of XAudio2

[Ethan Lee]

Starting to work on the allocator extension now, but while I'm doing 
that there are some other things to think about:

 From FAudio's end: The allocator extension has plenty of use cases I 
can think of, but ripping up the whole platform layer into a publicly 
exposed part of FAudio is... I don't want to outright say it crosses the 
line, but it definitely begs the question of who actually needs this 
aside from Wine. It's absolutely been done before, as can be seen with 
FMOD's output plugin system...

https://www.fmod.com/docs/api/content/generated/FMOD_System_RegisterOutput.html

... but looking around the web I couldn't find a single shipping use 
case other than my own, which solely exists because FMOD is proprietary 
and I can't fix their Linux support properly:

https://github.com/flibitijibibo/FMOD_SDL

And keep in mind, there are plenty of "platform" functions that I 
definitely wouldn't expose, including threading, time, fixed-rate SRC 
(which admittedly shouldn't be a platform thing), etc.

 From Wine's end: There are a couple more things that Wine cares about 
that are very specific and useless in the general case, but would be 
important for accuracy and 100% API/DLL coverage. An example that our 
runtime version checking does not and cannot cover in release builds is 
support for the debug versions of all the libraries, which includes 
support for XAUDIO2_DEBUG_CONFIGURATION:

https://github.com/FNA-XNA/FAudio/blob/7f9f76ac97096374904eaf2c444dccca2036731f/src/FAudio.h#L252

This is only functional in the debug FAudio binaries, but Windows games 
can ship with support for running debug contexts alongside the standard 
release config (I'm aware of at least one game that does this) and so 
you would need to be able to build an FAudio version that provides all 
the debug information that this structure asks for if you wanted to be 
accurate (or at least, useful). For other FAudio customers they just 
build their own debug binary, or if they statically link, they build 
their game in debug mode and it just works out.

Lastly, from distributors' perspectives: We still haven't figured out if 
distributors are even willing to put up with packaging FAudio on its 
own, let alone add it to their dependency list for Wine. It's a really 
small package, so I'm optimistic that they'd at least check it out, but 
I know 100% that they would not ship it the way we'd want them to. Say 
hello to our upcoming optional FFmpeg dependency:

https://github.com/FNA-XNA/FAudio/pull/46

We already know right out the gate that a percentage distributions 
aren't going to enable this in builds (the distro I use is one of 
them!). That's not to say they'd suddenly enable it if it was statically 
linked in Wine, but the question we need to ask is, what are we going to 
tell users whose distro did not build with this enabled? Do you want 
them rebuilding the xaudio2 module from the Wine source, or do you want 
all your customers to come to me...? I like to think my support quality 
is okay for a 1-man team but I can't promise that I'll be able to handle 
that added traffic, or that they'll be able to separate the FAudio 
project from the Wine project, and that could have unintended 
consequences if something goes wrong (that's a two-directional problem, 
for the record). It's easy for you and me to hash things out, but what 
about everyone on the outside?

-Ethan

On 10/22/18 08:18, Andrew Eikum wrote:
> On Fri, Oct 19, 2018 at 06:09:19PM -0500, Ken Thomases wrote:
>> On Oct 19, 2018, at 2:07 PM, Alexandre Julliard <julliard at winehq.org> wrote:
>>> Henri Verbeet <hverbeet at gmail.com> writes:
>>>
>>>> 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.
>>> Yes, clearly this would be the preferred approach.
>> Is there any need/desire/benefit for XAudio2 to go through the other Windows audio APIs (e.g. MMDevAPI, WASAPI) for proper integration?  Coherent enumeration of devices?  Audio mixing from different APIs?  Client control of audio devices?  User control via winecfg or the registry?
>>
> Yes, we need to use and output through Wine's mmdevapi. There are
> cross-API structures that should function (device IDs, default device
> selection, global mixer state). I think it wouldn't be hard to provide
> user hooks for that functionality in FAudio, like they're working on
> for the allocator stuff.
>
> There's code for it at https://github.com/FNA-XNA/FAudio/issues/31 ,
> it just needs to be formalized into the FAudio API.
>
> Andrew
>