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@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.