First Inbound Call Reports Waveinopen Error

[Guest Dougal]

Hi,

I'm investigating a problem where the first inbound call is answered, a prompt is played and then the call gets dropped. Subsequent calls, however, succeed and there are no problems.

 

The VG logs only contain the following message:

094533.010 ocxfn RecStart(sLineId:13, strFile:D:\Tools\VoiceGuide\Voiceguide_script\testrec1.wav)
094533.010 wavec waveOutReset(0x197594) call, caller: RecSoundStart
094533.020 wavec waveOutReset(0x197594) => 0 (MMSYSERR_OK), caller: RecSoundStart
094533.020 wavec waveOutClose(0x197594) call, caller: RecSoundStart
094533.020 wavec waveOutClose(0x197594) => 0 (MMSYSERR_OK), caller: RecSoundStart
094533.020 fn    rec   waveInOpen failed.

 

However, in my wave audio driver, I do not see any call to waveInOpen (WIDM_OPEN) so I was hoping that I could at least see what the return code from waveInOpen() is as it might provide some insight as to what is going wrong.

 

The only clues I can provide are in the second call, there is a slightly different order of events:

094636.342 wavec waveOutReset(0x22f6dc) call, caller: Psch
094636.342 wavec waveOutReset(0x22f6dc) => 0 (MMSYSERR_OK), caller: Psch
094636.342 wavec waveOutClose(0x22f6dc) call, caller: Psch
094636.342 wavec waveOutClose(0x22f6dc) => 0 (MMSYSERR_OK), caller: Psch
094636.342 fn    OnFirePlayPlayWdogClearEvent start
094636.342 ocxev PlayWdogClear(dwLineId=13, dwPlayId=0x29f2cb4)
094636.342 ocxev PlayEnd(dwLineId=13, dwPlayId=0x6b635)
094636.352 ocxfn SilenceDetectSet(sLineId=13, sTimeLen=30, sVolumeLevel=10)
094636.352 ocxfn RecStart(sLineId:13, strFile:D:\Tools\VoiceGuide\Voiceguide_script\testrec1.wav)
094636.352 wavec waveInOpen(0x0, 0x0, 0x12e600, 0x3a36240, 0x3ea7660, 0x1) => 0 (format: 8k16m)
094636.362 wavec waveInOpen(0x3eb4800, 0x0, 0x12e600, 0x10110, 0x3ea7660, 0x10000) => 0

 

In this instance the wave audio output device is closed before RecStart is invoked. In the failing case, RecStart appears to be called before waveOutReset/waveOutClose.

 

I've attached log extracts from the first inbound call and the second inbound call in the hope that someone might be able to determine what the significant difference is.

 

Thanks

VoiceGuide.log

[SupportTeam]

What is the telephony device which you are using?

 

If it’s Eicon then please obtain the latest drivers for it - others have reported all sorts of problems with older Eicon drivers but the latest release from them apparently work OK (search this forum for "Eicon" to find other posts).

[ktruk]

Support: Just an FYI The latest Eicon drivers do not work okay. 1) PLAYBACK: The v7.70 and v8.00 (latest) drivers will playback 8KHz 8/16bit WAVs but each line hangsup on the first call to the line, but plays the wav on the second or subsequent call, no problem. 2) RECORD: both versions of the wave-driver refuse to record a wav-file. VG reports an error-code returned from the eicon driver. See my previous posts(!): http://voiceguide.com/forums/index.php?showtopic=3765

[SupportTeam]

OK, Thanks.

 

So looks like to use Eicon for systems where recording is required the ComISDN driver will be needed, but Eicon’s TAPI/WAV drivers should be fine for systems where recording is not required, correct?

[ktruk]

Nearly: The first call to any line after VG is started is hungup. I think this is the issue that Dougal above is referencing.

 

If recording is needed then currently the Eicon drivers do not work at all. It is unclear where the problem lies. VG Support have stated previously that the eicon driver returns an error code. However, the error code is returned by what looks like a start-recording call to the VG OCX.

 

I can confirm that ComISDN definately does provide a workaround for this recording problem and incdentially, the first-call problem... But looking at Dougal's post above, there does seem to be an issue with the VG WaveInOpen() call highlighted above. Perhaps you can give this another going over?

[SupportTeam]

We'd need to see the "tw" trace to see what the call to waveInOpen retuned - but again ultimately it is the TSP that is retuning the error - the log is just relaying what error code was returned...

[Guest Dougal]

Thanks for the responses.

 

SupportTeam, you can find the "tw" trace extracts attached to my OP above (VoiceGuide.log).

[SupportTeam]

Please update your system with this new .OCX.

Update just involves copying the new ocx over the old one.

 

If backing up the old ocx please remove it from the system altogether.

The new OCX version is 1.86. You can confirm the new OCX is used by looking at the "tw" log after restart - v1.86 should be displayed in the header logged on restart.

 

If you encounter any problems please post traces as before.

TapiWrap_1.86.zip

[SupportTeam]

Could you please provide the complete "tw" and "vgm" traces showing the full inistialisation of the system and one incoming call when the ocx provided above is used.

 

Which Eicon card is being used here?

[Guest Dougal]

Well that seems to have done the trick

 

The call on no longer disconnected when recording starts.

 

Just for completeness' sake, I'm attaching a ZIP with logs for the older 1.84 and newer 1.86 OCX runs.

 

I was using a Diva Server V-4BRI and 8.0 drivers from the Eicon website.

VG.zip

[SupportTeam]

OK, good to hear it's working fine now.

If you come across any other issues please let us know.