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

[Nikolay Sivov]

On 5/1/19 9:06 PM, Ethan Lee wrote:

> All of the changes are relatively easy to avoid until you get to CommitChanges, which was completely wrong to begin with. It was either wait and let more software become dependent on the incorrect function signature or break right away and get the unavoidable pains out of the way sooner than later. Either way, these ifdefs were going to happen. Breaking compatibility for one single function seemed really awful, so I tried my best to update the rest of the API to be more consistent across the board to justify the breakage a bit more (for example, properly making 2.8+ functions with the ‘8’ suffix). My hope is that this will keep us from having to break it again in the future.
The problem is that distros will never catch up with changes like that 
in reasonable timeframe, and this change gives another reason to avoid 
packaging this library.
>
> Other than CommitChanges, the rest of the changes aren’t terribly interesting, except for F3DAudioInitialize8 which now returns an error code if the input parameters are invalid, which is accurate for 2.8 and higher.
Can you verify arguments in wine code instead? I think it makes sense to 
keep faudio independent of various xaudio versions specifics, if doesn't 
depend already.
>
> -Ethan
>
>> On May 1, 2019, at 1:57 PM, Alexandre Julliard <julliard at winehq.org> wrote:
>>
>> elee at codeweavers.com writes:
>>
>>> diff --git a/dlls/xaudio2_7/x3daudio.c b/dlls/xaudio2_7/x3daudio.c
>>> index ee3367e092..f08a425ca1 100644
>>> --- a/dlls/xaudio2_7/x3daudio.c
>>> +++ b/dlls/xaudio2_7/x3daudio.c
>>> @@ -51,8 +51,12 @@ HRESULT CDECL X3DAudioInitialize(UINT32 chanmask, float speedofsound,
>>>          X3DAUDIO_HANDLE handle)
>>> {
>>>      TRACE("0x%x, %f, %p\n", chanmask, speedofsound, handle);
>>> +#if FAUDIO_ABI_VERSION >= 1
>>> +    return F3DAudioInitialize8(chanmask, speedofsound, handle);
>>> +#else
>>>      F3DAudioInitialize(chanmask, speedofsound, handle);
>>>      return S_OK;
>>> +#endif
>> Was it really necessary to break binary compatibility so soon, and force
>> us to maintain ugly ifdefs and multiple builds of the library?  It looks
>> like it wouldn't be hard to avoid it.
>>
>> -- 
>> Alexandre Julliard
>> julliard at winehq.org
>
>