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

[Derek Lesho]

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.
>>