[PATCH 1/2] xaudio2: Fix support for FAudio 19.06 and newer

[Chris Robinson]

On 5/2/19 10:29 AM, Ethan Lee wrote:
> Those names definitely look messy, but not quite messy enough… I’ll keep thinking of a good name, but for now (at least for demonstration purposes) I’ve gone ahead and used ‘BADABI’ to lay out how this is going to go down:
> 
> https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135fc4/include/FAudio.h#L662 <https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135fc4/include/FAudio.h#L662>
> 
> https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135fc4/include/FAPOFX.h#L159 <https://github.com/FNA-XNA/FAudio/blob/16d1dfeb92a4ae18eacb67c3dcf3f75de5135fc4/include/FAPOFX.h#L159>
> 
> So I’ve added the fixed functions and that’ll work for the rest of 2019 - this can safely be used for all of Wine 4.x and 5.0, and the function used by 4.3 through 4.7 (or 8 or 9, depending on when you want to move to the corrected function) can still build against the old function.

Apologies for butting in, but I'm not sure this is any better. Code 
that's written to call FAudio_CommitChanges would expect this function 
to have the same specified behavior after an update. If code needs 
updating to use the new version, having a separate 
FAudio_CommitChangesBADAPI function seems a bit pointless; for the same 
effort of changing the call to restore old behavior, you could just 
ensure FAudio_CommitChanges is used correctly (unless the behavior 
change is that significant, in which case it really should be a new 
function).

When it comes to ABI changes, it should represent a massive change for 
the interface and be a complete refresh. If you have libfaudio.so.0 and 
libfaudio.so.1, for example, what happens if a process tries to pull in 
both (e.g. the main app links against libfaudio.so.1, but the app also 
links against libfoo.so which links to libfaudio.so.0)? Now you have two 
separate FAudio_CommitChanges symbols with two different behaviors, and 
something will break. I've actually run into this problem with SDL, 
where I link against SDL2 and SDL_sound, but on some distros SDL_sound 
links against SDL1; it all compiles and links fine, but misbehaves at 
runtime for no immediately obvious reason (if I didn't know SDL_sound 
might be linked against SDL1, while I link against SDL2, I'd be baffled 
as to why seemingly correct calls are just failing for some people and 
not others).