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.