Voxware audio codec not loading on win32

[compn]

Voxware audio does not work on mingw mplayer (have not tested cygwin, but i
believe its a win32loader problem).

Warning: DS_Filter() could not connect to output pin. (DLL=voxmsdec.ax,
r=0x8004020e)
ERROR: Could not open required DirectShow codec voxmsdec.ax.
samples in ​ftp://ftp.mplayerhq.hu/MPlayer/samples/A-codecs/VoxWare/ dir.

[mplayer@…]

For me the error is different:
Opening audio decoder: [dshow] Win32/DirectShow decoders
Warning: DS_Filter() source format is not accepted. (DLL=voxmsdec.ax, r=0x1)
ERROR: Could not open required DirectShow codec voxmsdec.ax.

Anyway directshow cannot render it, the used way to reproduced it by m$ stuff is
using the acm wrapper included in this cab:
​http://codecs.microsoft.com/codecs/i386/voxacm.CAB

Yes it contains also dshow codecs but installing it, directshow uses acmwrapper,
I'll check acm compatibility.
Btw manual registration of the ax codec causes graphedit to use it.
I'll investigate more, The codecs supports 62/69/75 source formats so it should work

[mplayer@…]

sorry but I was not using also msms001.vwp, so the error is the same, other my
considerations are ok

[mplayer@…]

Depending on component missing or not the error is a problem on input/output
pin... I cannot get acm codec working (maybe I've not enabled acm in my build),
I'll setup also here a compile environment so I can enable debug and other
stuff, my opinion is that codec needs different input or output pin type, very
strange since input types are 62 (Duck DK3 ADPCM ??) / 69 (Unknown) and 75 ( I
think they can added to codecs conf) and output pin is PCM

[mplayer@…]

I've got new infos,
CBasePin::ReceiveConnection returns this error
0x8004020E - Buffers cannot be set with this alignment.

So playing with buffer size could solve the problem

[mplayer@…]

Mplayer dump:
Format Tag: 1 (0x1)
Channels: 1
Samplerate: 16000
avg byte/sec: 32000
Block align: 2
bits/sample: 16
cbSize: 0

Data from graphedit using a working connected graph:
wFormatTag: 1
bChannels: 1
nSamplesPerSec: 16000
nAvgBytesPerSec: 32000
nBlockAlign: 2

I don't have a way to check wBitsPerSample
in graphedit...
parameters should be ok, but the filter doesn't like the output pin...

[saschasommer@…]

Take into account that this decoder dll works on linux,
I tryed to debug it a bit and the problem seems to be in the
MemAllocator. On linux we are using the one from allocator.c
whereas on windows this one is only used for COutputPin_GetAllocator.

The dll calls it in the following sequence when Receiving the Outputpin:
MemAllocatorCreate() called -> 0x86b88f8
MemAllocatorCreate() called -> 0x86b8990
MemAllocator_QueryInterface(0x86b8990) called
MemAllocator_AddRef(0x86b8990) called (ref:1)
MemAllocator_Release(0x86b8990) called (new ref:1)
MemAllocator_AddRef(0x86b8990) called (ref:1)
MemAllocator_GetProperties(0x86b8990) called
MemAllocator_Release(0x86b8990) called (new ref:1)
MemAllocator_SetProperties(0x86b88f8) called

On windows the second area gets allocated via the allocator registered in the
com, therefore the lines with 0x86b8990 do not get printed.
MemAllocator_SetProperties then gets called with the values cBuffers=0 and
cbBuffer=1 what makes this call fail.
Reasons for this might be invalid struct packing. Adding attribute(packed)
to the relevant structs may help.
It is also possible that the MemAllocator does not get emulated correctly,
because there is still the question why it works on linux but not on windows.
This makes me think that the values from the second allocator (the one with
0x86b8990) get used to calculate the properties for the first.
It is possible that the default values by the emulated MemAllocator are not
correct then.

[mplayer@…]

The problem is in quartz.dll, I was tring to debug with gdb but mingw compiles
have problems stucking in ws2_32 library (very annoing, most like winsock
library has some breakpoint by int3). I'll try to debug using native windows
tools. Btw there is as short way to disable optimizations at all (-O0)?
It's a good thing that gdb enables debugging in optimized code, but I've some
problem to follow the program flow :P

[mplayer@…]

Update: I've compiled mplayer with -mms-bitfields and the result is the same, I
suspect the problem is not in the structs, also other filters are working fine

[mplayer@…]

Anyway you are right, the function that fails is CMemAllocator::SetProperties in
quartz.dll, on linux it's emulated

[voroshil@…]

Fixed in r22322