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

[Zebediah Figura (she/her)]

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?
-------------- 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/cbd97f05/attachment-0001.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/cbd97f05/attachment-0001.sig>