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

[Zebediah Figura (she/her)]

On 12/2/20 3:49 PM, Derek Lesho wrote:
> 
> 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?
> 

It seems that way to me, yes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x0D9D358A07A17840.asc
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201202/4d94f343/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201202/4d94f343/attachment.sig>