We're experiencing an issue with our Lumenvox Speech Recognition installation with TeleFlow. <br> <br>An ACCESS_VIOLATION error is thrown often when the timeout is reached during a SR Get Digits function. <br> <br>Attached is a log of this occurrence. <br> <br>Let me know if there is additional info from us. <br> <br>Jun 07 09:15:55.21: Main<==SetGlobals <br>Jun 07 09:15:55.21: [5] Play <br>Jun 07 09:15:55.21: Script code 'Vox\Eng\Scripts\Intro.Vox' evaluates to 'Vox\Eng\Scripts\Intro.Vox' <br>Jun 07 09:15:55.21: Playing 'C:\Program Files\TeleFlow\Applications\BJsClubLocator\Vox\Eng\Scripts\Intro.Vox' <br>Jun 07 09:15:55.21: Call Status (lps0) <br>Jun 07 09:15:55.21: ATDX_HOOKST (2) <br>Jun 07 09:15:55.21: Call Status (lps0) <br>Jun 07 09:15:55.21: ATDX_HOOKST (2) <br>Jun 07 09:15:55.21: Call Status (lps0) <br>Jun 07 09:15:55.21: ATDX_HOOKST (2) <br>Jun 07 09:16:05.24: [145] Wait <br>Jun 07 09:16:05.24: Waiting 500 milliseconds <br>Jun 07 09:16:05.74: [11] Run Flowchart <br>Jun 07 09:16:05.74: Flowchart: 'GetZip' <br>Jun 07 09:16:05.74: Main==>GetZip <br>Jun 07 09:16:05.74: [1] START <br>Jun 07 09:16:05.74: [56] Run Flowchart <br>Jun 07 09:16:05.74: Flowchart: 'SetMarker' <br>Jun 07 09:16:05.74: Setting local variable '@NEWMARKER' to '5' <br>Jun 07 09:16:05.74: GetZip==>SetMarker <br>Jun 07 09:16:05.74: [1] START <br>Jun 07 09:16:05.74: [6] Compare <br>Jun 07 09:16:05.74: @NEWMARKER > @LASTMARKERID? <br>Jun 07 09:16:05.74: (integer):5 > (integer):0? <br>Jun 07 09:16:05.74: TRUE <br>Jun 07 09:16:05.74: [4] Set Global Variable <br>Jun 07 09:16:05.74: Setting global variable '@LASTMARKERID' to '5' <br>Jun 07 09:16:05.74: [2] FINISH <br>Jun 07 09:16:05.74: GetZip<==SetMarker <br>Jun 07 09:16:05.74: [57] Run Flowchart <br>Jun 07 09:16:05.74: Flowchart: 'CheckForTransferNeed' <br>Jun 07 09:16:05.74: GetZip==>CheckForTransferNeed <br>Jun 07 09:16:05.74: [1] START <br>Jun 07 09:16:05.74: [4] Set Local Variable <br>Jun 07 09:16:05.74: Setting local variable '@TYPEAHEAD' to '-1' <br>Jun 07 09:16:05.74: [3] Pending TT <br>Jun 07 09:16:05.74: Setting local variable '@TYPEAHEAD' to '' <br>Jun 07 09:16:05.74: [23] Clear TT <br>Jun 07 09:16:05.74: [16] Compare <br>Jun 07 09:16:05.74: @TYPEAHEAD = 0? <br>Jun 07 09:16:05.74: (string): = (integer):0? <br>Jun 07 09:16:05.74: FALSE <br>Jun 07 09:16:05.74: [19] Compare <br>Jun 07 09:16:05.74: @TYPEAHEAD = *? <br>Jun 07 09:16:05.74: (string): = (string):*? <br>Jun 07 09:16:05.74: FALSE <br>Jun 07 09:16:05.74: [2] FINISH <br>Jun 07 09:16:05.74: GetZip<==CheckForTransferNeed <br>Jun 07 09:16:05.74: [3] Play <br>Jun 07 09:16:05.74: Script code 'Vox\Eng\Scripts\AskForZip.Vox' evaluates to 'Vox\Eng\Scripts\AskForZip.Vox' <br>Jun 07 09:16:05.74: Playing 'C:\Program Files\TeleFlow\Applications\BJsClubLocator\Vox\Eng\Scripts\AskForZip.Vox' <br>Jun 07 09:16:05.74: Call Status (lps0) <br>Jun 07 09:16:05.74: ATDX_HOOKST (2) <br>Jun 07 09:16:05.74: Call Status (lps0) <br>Jun 07 09:16:05.74: ATDX_HOOKST (2) <br>Jun 07 09:16:05.74: Call Status (lps0) <br>Jun 07 09:16:05.74: ATDX_HOOKST (2) <br>Jun 07 09:16:14.37: [52] Beep <br>Jun 07 09:16:14.37: Call Status (lps0) <br>Jun 07 09:16:14.37: ATDX_HOOKST (2) <br>Jun 07 09:16:14.37: Playing audio buffer... <br>Jun 07 09:16:14.57: [48] SR Get Digits <br>Jun 07 09:16:14.57: No voice TIMEOUT '2000' evaluates to 2000 <br>Jun 07 09:16:14.57: End of speech timeout: 500' <br>Jun 07 09:16:14.57: Threshold confidence '25' evaluates to 25 <br>Jun 07 09:16:14.57: Setting global variable '@ZIPIN' to '' <br>Jun 07 09:16:14.59: Call Status (lps0) <br>Jun 07 09:16:14.59: ATDX_HOOKST (2) <br>Jun 07 09:16:24.62: LumenVox: [PortLog:20][PortNum:18]LoadVoiceChannel CreateSoundFile_Format() <br>Jun 07 09:16:24.62: 5D766C9: EXCEPTION_ACCESS_VIOLATION attempting to read at location 76F4000. <br>Jun 07 09:16:24.62: Exception occurred! Thread exiting. <br>Jun 07 09:16:24.62: Attempting ag_unlisten, lines[curLine].chdev = 0x2 <br>Jun 07 09:16:24.62: ag_unlisten - success <br>Jun 07 09:16:24.65: dx_close <br>Jun 07 09:16:24.65: ReleaseLine done. <br>Jun 07 09:16:24.65: XMLList destructor done <br>Jun 07 09:16:27.68: <br> <br> <br><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< END LOG >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

On the "SR Acquire" step, ensure that the "Enable Speech Recognition Barge-in" check box is un-checked. Also, make sure you do not have any "SR Barge-In On" or "SR Barge-In Off" steps anywhere in your application. <br> <br>Try that and see if you still get the access violation. If so, please advise if the SR step works otherwise, ie: if the caller speaks you don't get the error, correct?

I've been unable to replicate the issue. It is happening rather infrequently and is difficult to chase down. <br> <br>Since 9am yesterday we've had a total of 20 occurrences of this error and a total of 185 calls. This means that the error is occurring on roughly 10%-11% of all calls. <br> <br>I've forwarded log files from the two lines that it occurred on yesterday to the support mailbox. <br> <br>Let me know if there is additional information you need from me.

Lets eliminate the possibility of a mis-match of files. Can you send us a list of all the files in your C:\Program Files\TeleFlow folder, ordered by extension then by name. Here's the easiest way to do that: <br> <br> Open a command prompt <br> CD to C:\Program Files\TeleFlow <br> type: <br> dir/oen > tffiles.txt <br> email "tffiles.txt" to support@engenic.com

The file has been sent.

We've reviewed this list. All your TeleFlow files are the same. That's the good news. I want to do more testing here in our lab, based on the information in the log files you sent. Will report back here when I know more.

Here's the problem: Dialogic's record-to-memory function is not respecting the maximum record length of 10 seconds, which corresponds to the size of the buffer reserved for SR recordings. In order to trigger this bug, there has to be noise on the line for the full 10 seconds and them some. This is why it only happens about 10% of the time. <br> <br>I suspect this means it is not affecting your callers because few people are likely to take more than 10 seconds to speak a zip code. More likely, is that you do not get loop current drop on a disconnected call, and so the Dialogic card is recording a reorder tone (which lasts indefinetly). <br> <br>To verify this assumption, call the service that experiences this problem, wait until it is asking for the zip code, and then hang up. Watch the monitor and check the log. If it gives an access violation, I think its safe to assume that most, if not all, of these occurrences are triggered by a caller hangup. <br> <br>Please let us know what happens. We will see if we can find a work-around for the Dialogic issue.

I called our IVR and hung up at the zip code prompt. I did not receive the error. <br> <br>However, I did call into the IVR and continuously blew air into the handset of my phone for 10 seconds. This caused the error. <br> <br>Obviously this is a big deal because it is certainly possible for a user to be on their cell phone and be in a loud environment that may prevent the IVR from cutting off at the 10 second limit. <br> <br>Unfortunately, at one point last week our client tested our system and experienced this error 7 times in a row. <br> <br>I spoke with them this morning and they were not in an environment that had a lot of background noise, and in many cases they were using their keypad to respond to the prompts instead of using Speech Recognition. It sounds like your solution may solve a portion of the problem, but according to my client, it does not explain their experience. <br> <br>-Jeff