Integrating FAudio, a reimplementation of XAudio2

[Andrew Eikum]

Hey all,

Our current xaudio2 implementation uses OpenAL to do the mixing before
sending audio to hardware. We're running up against limitations of the
OpenAL API such that it makes sense for us to write our own mixing
code.

Luckily, someone has already done this. Ethan Lee, who maintains the
FNA reimplementation of the XNA game libraries, wrote an
implementation of the XAudio2 API called FAudio[1]. FAudio is far more
advanced than Wine's current XAudio2 implementation. I'd like to take
advantage of his work, rather than re-invent this wheel. Much of this
work has already been done, the question is how to upstream the
integration into Wine.

The licenses are compatible, but the tricky part is Wine isn't the
only customer of FAudio, so we have to be mindful of other external
requirements on FAudio.

I discussed some options with Ethan over private email. You can see
the latest reply from Ethan below. I'd like to get more feedback from
the community.  Does anyone have any other ideas, or strong feelings
about the right way to use Ethan's code in Wine?

[1] https://github.com/FNA-XNA/FAudio/

Thanks,
Andrew

----- Forwarded message from Ethan Lee <flibitijibibo at flibitijibibo.com> -----
On 10/18/18 08:40, Andrew Eikum wrote:
> On Wed, Oct 17, 2018 at 06:11:37PM -0400, Ethan Lee wrote:
> > Since we’re building FAudio directly into the XAudio2 source, how
> > should I go about including the source in that folder? I just want to
> > be sure I’m doing it in a way that Wine upstream will be okay with;
> > codewise I think we’re doing everything okay (no added dependencies,
> > FFmpeg is optional, etc.) but since this is effectively a mirror of a
> > separate project I wasn’t sure if I needed to do anything more than a
> > folder with a README containing FAudio’s Git hash and a date.
> > 
> 
> Yep, this is going to be the hard part. I can think of a few options,
> ranked in order of how I think upstream (Julliard and the rest of the
> Wine community) would like it:
> 
> -Make Wine the home of FAudio. We'd import all of the C files, and any
> changes to FAudio would have to go through the usual Wine submission
> process, including our requirement for tests. You would have to
> somehow integrate Wine's source into FNA somehow in order to pull
> FAudio into your other builds. The requirement for tests would
> actually be a big plus for FAudio in terms of matching Microsoft's
> behavior. We aren't sticklers about tests for no reason. I don't know
> if this would require a re-license to LGPL; perhaps we can keep just
> xaudio2 stuff as zlib.
> 

1. Probably no to the home change, and definitely no to the license change.
One of the big motivations for FAudio's creation was the zlib-licensed
implementation, which is mandatory for platforms like iOS/Switch/Sony. Plus, I
don't own 100% of the rights, so we'd have to do another relicensing round,
which may not go as well as last time. The home change wouldn't be the worst
thing but it'd be tough explaining to the average FNA user (and most other
devs, now that I think about it) that they have to dig into the Wine tree
first.

> -Distribute FAudio as a library and build Wine against that. Similar
> to how we depend on OpenAL currently. This has some challenges in
> terms of getting distro maintainers to bother building it, but I think
> it won't be too tough. We can follow VKD3D's lead here in terms of
> gathering distro support. If you're not careful when pushing out
> FAudio updates, you may break the Wine tests, and our users, which
> would be unfortunate (and poorly received by the other Wine devs).
> 

2. Second best option IMO, though we would need to work around the CoTaskMem
exposure in the XAPO/XACT APIs.

> -Use a Git submodule. Wine doesn't do this at all currently, but maybe
> we could convince them. This would let Wine control precisely which
> revision of FAudio is used, preventing regressions due to upstream
> changes. It does complicate the Wine build somewhat, and makes
> distributing Wine source significantly more complicated.
> 

3. I'd be okay with this but I could also totally understand why it would be
avoided. Git submodules are surprisingly user-unfriendly! We use submodules in
FNA but explaining them to new users has definitely taken a few minutes of my
time over the years.

> -Just copy the source straight over and periodically merge in updates
> from FAudio upstream. Git has a subtree-merge feature that can do this
> relatively elegantly. This has the disadvantage that we now have two
> full copies of the FAudio source that must be maintained, instead of
> storing it all at one location. Again, potential licensing
> complications.
> 

4. I think this is the best route, but at the same time I think I can sweeten
the deal a whole lot more. One possibility is giving the WASAPI platform
entirely to Wine so the team has total control over the platform subsystem
(including the license), and while FAudio's core would be primarily developed
elsewhere, I can formalize the release process a whole lot more so updates can
be reviewed with more consistency, and possibly more participation from Wine
maintainers if needed. For example, when Johan sends his xWMA PR the two of us
can both do a review of the patchset, and only when both reviews are cleared
will we do the merge. At the moment FAudio releases are bundled with FNA
releases, which are always on the first of every month, but if the Wine team
are more comfortable with FAudio getting dedicated releases (but with the same
schedule) I can do that as well.