Opened 16 years ago

Closed 14 years ago

#16 closed defect (fixed)

Voxware audio codec not loading on win32

Reported by: compn Owned by: saschasommer@…
Priority: normal Component: ad
Version: 1.0pre5 Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:


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. (,
ERROR: Could not open required DirectShow? codec
samples in dir.

Change History (11)

comment:1 Changed 16 years ago by saschasommer@…

  • Owner changed from alex@… to saschasommer@…

comment:2 Changed 16 years ago by mplayer@…

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

Anyway directshow cannot render it, the used way to reproduced it by m$ stuff is
using the acm wrapper included in this 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

comment:3 Changed 16 years ago by mplayer@…

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

comment:4 Changed 16 years ago by 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

comment:5 Changed 16 years ago by 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

comment:6 Changed 16 years ago by 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...

comment:7 Changed 16 years ago by saschasommer@…

  • Status changed from new to assigned

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.

comment:8 Changed 16 years ago by 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

comment:9 Changed 16 years ago by 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

comment:10 Changed 16 years ago by mplayer@…

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

comment:11 Changed 14 years ago by voroshil@…

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in r22322

Note: See TracTickets for help on using tickets.