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.h...
... 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/7f9f76ac97096374904eaf2c444dccca20367...
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@winehq.org wrote:
Henri Verbeet hverbeet@gmail.com writes:
On Fri, 19 Oct 2018 at 19:51, Henri Verbeet hverbeet@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