[PATCH 2/2] xaudio2: Add support for xactengine3

[Ethan Lee]

I may have to dig into this some more then; it definitely seems wrong to push the types into a global header, but at the same time we _really_ need those internals. Right now I’m looking in other DLLs and the closest thing that seems right is the `unsafe_impl_*` route, such as this one here:

https://github.com/wine-mirror/wine/blob/06531b1d9898ba3ac3b7c69d6192682202606f8f/dlls/d3d11/state.c#L427

This is better than what I have now in that it only returns a value if it’s actually from the Wine DLL and not the MS version. The problem for us is that this example has everything in the same DLL; for XACT I would still need to depend on the XAudio DLL to compare the vtbl value.

It’d be much better, but still not perfect, but I don’t know if perfect is entirely possible given how tightly-coupled XAudio and XACT are in this way.

(On the bright side, this patch is totally separate from patch 1, so if the XAudio2 stuff is good, this can be ignored until we figure out what to do.)

-Ethan

> On Feb 18, 2019, at 1:28 PM, Alexandre Julliard <julliard at winehq.org> wrote:
> 
> Ethan Lee <elee at codeweavers.com> writes:
> 
>> If that’s the case then we’ve got a problem… at minimum we need this:
>> 
>> https://github.com/flibitijibibo/wine/blob/faudio/dlls/xaudio2_7/xact_dll.c#L959
>> 
>> We need the FAudio data types from the XAudio2 types so that FAudio
>> can actually make use of the engine/master when the application
>> requests it. If we _absolutely positively must_ stay away from this,
>> those parameters will have to be ignored, which can potentially break
>> programs that need it. This is true of all the low-level XAudio
>> interop functionality in the XACT API.
> 
> If there are private type definitions that need to be shared they have
> to be put in a global header in include/wine, but that's strongly
> discouraged.
> 
> -- 
> Alexandre Julliard
> julliard at winehq.org