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#...
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.
-Ethan
On Feb 18, 2019, at 1:03 PM, Alexandre Julliard julliard@winehq.org wrote:
Ethan Lee elee@codeweavers.com writes:
XACTEngine is similar to X3DAudio/XAPOFX in that they’re separate DLLs from XAudio2, but are still very tightly coupled with XAudio2 itself. In XACT’s case, we depend on both xaudio_private.h and xaudio_allocator.c, due to the need to unravel the engine/voice pointers as well as keep the exact same custom allocator callbacks as the rest of the XAudio DLLs, per FAudio’s request:
https://github.com/FNA-XNA/FAudio/blob/master/extensions/CustomAllocatorEXT....
That said, XACT didn’t get looped into XAudio 2.8+ like the other DLLs, so it would still make a little sense to have it in xactengine3_7 instead… if it’s okay for me to move the xact_* files but still depend on stuff in the xaudio2_7 folder, I can get that done today.
No, it's not OK to depend on stuff like that across DLLs. It should only be using the public API.
-- Alexandre Julliard julliard@winehq.org