Guest daveminker Report post Posted 10/02/2004 07:30 PM Every message that gets recorded is cut off both at the beginning and the end, by at least a second. I've attached the log of a sample call for review. Any help would be appreciated. Share this post Link to post
SupportTeam Report post Posted 10/02/2004 08:19 PM Are you using a Dialogic card or a voice modem? Please post the trace showing the message being recorded as well as the recorded .wav file (.zip up the .wav file) Share this post Link to post
Guest daveminker Report post Posted 10/02/2004 10:44 PM I'm using a Dialogic VFX/40ESC card. I've attached all logs as well as the voicemail. Just so you know, I started speaking after the beep and counted from one to five and hung up after I spoke the word "five". You'll see from the message that the "one" is cut off as is the "five". Thanks. ~dave files.zip Share this post Link to post
SupportTeam Report post Posted 10/03/2004 12:54 AM Trace from system shows that this card takes a fair bit of time to start playing/recording: Quote 182646.16 6 [VmLmRec] Recording 182646.70 6 PlaySoundStart ok [C:\Program Files\VoiceGuide\system\voice\beep1.wav] ... 182647.39 6 LsRecPlayBeep EV_PLAY_FINISHED ... 182648.07 6 RecSoundStart file[C:\Program Files\VoiceGuide\data\VmSave\3000_1002182645_1_6__.wav] ok How fast is the PC that you are using? What version of Dialogic System Release drivers are you using? Share this post Link to post
Guest daveminker Report post Posted 10/03/2004 03:07 PM It's a PII 300MHz and it's not running anything other than Win2K SP4 and the VG application. According to the Help screen in Dialogic's DCM, I'm running: Release SR5.1.1, Version DNA5, Build 30, Service Pack None Share this post Link to post
Guest daveminker Report post Posted 10/06/2004 12:52 PM Hi guys ... it has been a few days since I've heard from anyone on this and I'm really struggling with the problem. I'm losing the last few digits of people's phone numbers when they leave a voicemail and that makes it really hard to call them back... Please help! Thanks - Dave Share this post Link to post
SupportTeam Report post Posted 10/06/2004 08:40 PM The Dialogic cards which use the uLaw play/recording format (VFX/40ESC is one of those card) record in slightly different way to the other cards. This may have something to do with why you are seeing the end of the recording cut-off although we have not seen reports of this before... We'll need a bit more time to look into this issue... Share this post Link to post
Guest daveminker Report post Posted 10/22/2004 12:40 AM Please forgive my persistence with this issue, but i'm still having the same difficulty I originally described in the initial post. Can someone please advise on a course of action? Thank you. Share this post Link to post
SupportTeam Report post Posted 10/22/2004 02:59 AM We were unable to source a VFX/40ESC card to try to replicate your setup and see if we could reproduce the problem. I understand that that card is now discontinued... Is it possible for you to switch the card for a D/4PCI or other current card? Share this post Link to post
Guest daveminker Report post Posted 10/23/2004 07:26 PM I purchased the card because it was listed on your Recommended Dialogic Cards list at http://www.voiceguide.com/suppRecomHardware.htm and the vendor will not take the item back now. Isn't there any way to configure the VG settings to simply add some 'padding' at the end of the message?? I'm not nearly as concerned about the beginning of the message being cut off as I am about the cutoff at the end, which is where the phone numbers are being cut off because that's often times the last thing callers leave on a message before they hang up. Share this post Link to post
SupportTeam Report post Posted 10/23/2004 11:20 PM Traces show this system is running the program exceptionally slow. We have test systems in the office with similar CPU/speed like yours PII 300MHz, but we are seeing much faster running of the program on these computers. How much memory is on this system? Maybe the system is running so slow because it is constantly swapping memory out to hard disk? The slow system speed is the reason why the recording is not starting immediatley after the beep but about half a second later. As for why the end of recording is getting cut off: It is also possible that for some reason silence detection is triggered on this card too soon and that too much of the end is then truncated. I'd suggest trying to increase the silence detection timings - See VG.INI file, settings SilenceDetectLength and SilenceDetectLevel Quote 182647.39 6 LsRecPlayBeep EV_PLAY_FINISHED ... 182648.07 6 RecSoundStart file[C:\Program Files\VoiceGuide\data\VmSave\3000_1002182645_1_6__.wav] ok 182654.73 6 LsRecRecording EV_SILENCE_DETECTED 182655.01 6 rec length RV: VmLmRec_RecLen100ms = 42 182646.937 wavee WOM_DONE(0x25538dc, 0x259f4b8) (callback window message) ... 182647.598 ocxfn RecStart(sLineId:6, strFile:C:\Program Files\VoiceGuide\data\VmSave\3000_1002182645_1_6__.wav) ... 182654.638 tapie LINE_MONITORTONE(6, 0x10093, 0x1) 182654.768 ocxfn RecStopTruncate(sLineId=6, strSaveFname=, lTruncTime=30, lTruncBytes=33060) 182654.899 wavec waveInReset(0x25538dc) => 0 182654.979 linec lineMonitorTones(0x10093, 0x0, 1) => 0x0 (disabling monitoring for silence/tones) 182655.179 wavee WAVE_WIM_DONE(0x25538dc, 0x99153b0) 182655.209 wavec waveInUnprepareHeader(0x25538dc, 0x99153b0, 0x20) => 0 (MMSYSERR_OK), bytes in buff:5856 182655.239 rec silence detect end volmin=128 volmax=128, silcount=1524, (lSilCountResetVal=12000) 182655.269 rec WriteFile(handle:0x38c, dataptr:0x98fe008, bytes:5856, 1232160, 0) lSizeRecFile=20796 182655.289 wavee WAVE_WIM_DONE(0x25538dc, 0x2598a40) 182655.319 wavec waveInUnprepareHeader(0x25538dc, 0x2598a40, 0x20) => 0 (MMSYSERR_OK), bytes in buff:0 182655.349 rec WriteRiffChunk datasize=20796 182655.389 wavec waveInClose(0x25538dc) => 0 (MMSYSERR_OK) 182655.419 ocxev RecEnd(dwLineId=6, dwRecId=0x513c) Share this post Link to post
Guest daveminker Report post Posted 10/27/2004 02:15 PM The server has 320MB of RAM, so that shouldn't be an issue and changing those values in the VG.ini didn't have any effect on the cut-off of the end of the recording. Interestingly enough - if the voicemail is terminated by the caller hanging up on the line, we lose the last second or so. But if the recording is ended by the caller pressing a key on their keypad and then hanging up, none of the recording is truncated and we even hear the DTMF tone in the recording. Is there a setting somewhere in the setup of the Dialogic board that could be effecting this? Possibly something in the Dialogic TSP configuration on the "Call Parameters" screen? What about some of the AT parameters that are stored on the board itself? Reason I ask is because when I got the dialogic board it wouldn't report CID information on incoming calls - it wasn't until I opened a HypterTerminal session and issued an AT#CID=1 that it started to report CID on inbound calls. Is there something I can do to factory-reset the Dialogic board and make sure there aren't any settings in there messing things up??? Thanks - Dave Share this post Link to post
Guest daveminker Report post Posted 10/27/2004 02:47 PM One correction to the last post - I take back what I said about the CID information working: Quote Reason I ask is because when I got the dialogic board it wouldn't report CID information on incoming calls - it wasn't until I opened a HypterTerminal session and issued an AT#CID=1 that it started to report CID on inbound calls. I was mistaken - the CID information on the Dialogic board still isn't working either. I was configuring a different modem. Sorry for the confusion. Share this post Link to post
SupportTeam Report post Posted 10/27/2004 08:43 PM Have you tried turning of silence detection altogether? Which version of VoiceGuide are you using? Share this post Link to post
Guest daveminker Report post Posted 11/01/2004 06:28 PM I'm running version 5.2.2000 of VG Shutting silence detection off completely does prevent the end of the message from being cut off, but adds an extra 10 to 20 seconds (differs each time) of slience to the end of the message. While not ideal, it's OK for the short-term while we figure out what's really causing the problem. Share this post Link to post