[PATCH v2 1/4] winegstreamer: Introduce audio conversion transform.

[Derek Lesho]

On 12/2/20 4:47 PM, Zebediah Figura (she/her) wrote:
> On 12/2/20 3:37 PM, Derek Lesho wrote:
>> On 12/2/20 4:31 PM, Zebediah Figura (she/her) wrote:
>>> On 12/2/20 3:07 PM, Derek Lesho wrote:
>>>> On 12/2/20 4:01 PM, Zebediah Figura (she/her) wrote:
>>>>> On 12/1/20 2:06 PM, Derek Lesho wrote:
>>>>>> On 12/1/20 3:00 PM, Zebediah Figura (she/her) wrote:
>>>>>>>> +static HRESULT WINAPI audio_converter_ProcessMessage(IMFTransform
>>>>>>>> *iface, MFT_MESSAGE_TYPE message, ULONG_PTR param)
>>>>>>>> +{
>>>>>>>> +    FIXME("%p, %u.\n", iface, message);
>>>>>>>> +
>>>>>>>> +    return S_OK;
>>>>>>>> +}
>>>>>>> Why S_OK?
>>>>>> Because the media session sends some messages to the transform such as
>>>>>> MFT_MESSAGE_NOTIFY_BEGIN_STREAMING and fails to play if S_OK isn't
>>>>>> returned.  I take it you'd like me to actually implement this method
>>>>>> instead.
>>>>> Not necessarily, but if nothing needs to be done, then presumably there
>>>>> shouldn't be a FIXME either, and it's not obvious to me what needs
>>>>> to be
>>>>> done. Sorry, I guess that comment should have been more specific.
>>>> FWIW I've already sent a patch "implementing" this function in v3?
>>>> Should I remove it and just switch to a trace or just keep it as is?  I
>>>> think it may be better to keep it as is, since some messages not being
>>>> implemented may cause real problems.
>>>>>>> Why not CLSID_CResamplerMediaObject? In fact, we already have one
>>>>>>> application that needs it (bug 47781).
>>>>>> The only reason I didn't expose it as CLSID_CResamplerMediaObject is
>>>>>> that I didn't want to imply that I was basing the interface and types
>>>>>> supported off of that specific object.  For instance, that object,
>>>>>> from
>>>>>> what I can see on the MSDN, doesn't support PCM<->Float
>>>>>> conversions, and
>>>>>> vice versa.  Is this not a big enough deal to keep it separate?
>>>>>>
>>>>> Do we need to support integer/float conversion?
>>>> Yes, from what I've seen the SAR usually only supports one or the other,
>>>> at-least on wine.
>>> I'm not sure I understand; what do you mean by this?
>> The SAR on wine, at-least on my system, only accepts one input type (the
>> one derived from IAudioClient::GetMixFormat).  So we need to be able to
>> convert the one media type we are allowed to use from the source to the
>> one media type the SAR supports.  Naturally, you end up with cases where
>> one is floating point and the other is PCM.
>>>> Exposing a PCM and Float type from the source doesn't
>>>> solve this either, as the application doesn't have to specify
>>>> ENUMERATE_SOURCE_TYPES when loading the topology, and in practice,
>>>> rarely does, so the topology loader is forced to work with whatever the
>>>> default type happens to be.  It may be that on windows the decoders
>>>> almost always expose both a PCM and floating point type, but currently,
>>>> we are not using decoder MFTs in wine (and instead decoding in the media
>>>> source).
>>> It would be nice to confirm whether this is the case.
>> At-least for the MFTs I've seen so far, it is the case.  (both the AAC
>> decoder and WMA decoder guarantee a floating point and PCM output type)
>>>> In practice, what this means is that without PCM<->Floating
>>>> Point capabilities, Borderlands 3 doesn't work.
>>>>
> Okay, that's unfortunate, but makes sense. And there's no transform
> present on Windows which can do simple integer/float PCM conversion?
Not that I know of, and even if there was, the topology loader can only 
hook up one converter automatically.  Is this enough of a reason to stay 
with a custom object GUID for now?