Integrating FAudio, a reimplementation of XAudio2

[Ethan Lee]

CustomAllocatorEXT is now available:

https://github.com/FNA-XNA/FAudio/blob/master/extensions/CustomAllocatorEXT.txt

With this, we're now able to use our COM wrapper with a vanilla FAudio 
DLL using no custom paths. This at least fixes the worst problem we had, 
no matter which route we end up taking for the Wine built-in.

-Ethan

On 10/22/18 11:11, Ethan Lee wrote:
> 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
>>
>