Fileterm sample from SDK gets CME_STRAM_FAIL when trying to play a .WAV file

[David Goodenough]

I'd like to find out if this is a bug with the modem drivers I have, or whether I'm doing something wrong.

I built the fileterm sample from the SDK, found at "...\Microsoft SDKs\Windows\v7.1\Samples\netds\tapi\tapi3\cpp\fileterm", but when I run it it detects the incoming call, answers it, but then in DoCallMedia(), instead of getting the expected CME_STREAM_ACTIVE, I receive CME_STREAM_FAIL.

I'm using a USR 5637 USB voice modem, USB\VID_0BAF&PID_0303, with the following drivers:

C:\Windows\system32\drivers\modem.sys
C:\Windows\system32\drivers\usbser.sys

for the modem, and for the unimodem half duplex audio device, which I suspect is the voice portion of this, the drivers are:

C:\Windows\system32\drivers\ksthunk.sys
C:\Windows\system32\drivers\modemcsa.sys

Driver installation was done from the USR5637Voice64bit.exe file downloaded from US Robotics web page. Version 8.0.7600.16385.

Any ideas what's going wrong, and how I might fix this?

I saw a post from some time ago that mentioned it might be a half duplex problem, so I found the code that sets up the recording terminal in CreateAndSelectFileRecordTerminal() and commented out the block of code inside the following test:

if ( (S_OK==CheckStreamMT(pStream,lMediaTypes))
&& (S_OK==CheckStreamDir(pStream,TD_RENDER)))

and replaced it with the single call to

pStream->StopStream();

That didn't help.

[David Goodenough]

One other interesting discovery, this looks very much like a driver bug. The system where I originally did this was Windows 7 64 bit. When I installed the modem on an XP 32 bit system, Fileterm.EXE was able to play back the WAV file flawlessly.

So that means it looks a lot like a case of getting the drivers working properly. Unfortunately, when I ask Windows 7 to update the drivers, it tells me the ones I'm using are up to date. Any suggestions for how to proceed?