I have an app running and recently have received some complaints that some recordings are being cut off.
These are recordings that the people being called are leaving.
This is a snippet of the log file

2009/10/07 12:41:00.794: [505] Record
2009/10/07 12:41:00.794: Maximum record time is '180000'
2009/10/07 12:41:00.794: Silence TIMEOUT is '4000'
2009/10/07 12:41:00.794: Voice file '@VOXFILE' evaluates to 'D:\Program Files\TeleFlow\Applications\12705\Messages\09091007454375Q17.wav'
2009/10/07 12:41:00.794: Recording 'D:\Program Files\TeleFlow\Applications\12705\Messages\09091007454375Q17.wav'
2009/10/07 12:41:01.060: Event: ADIEVN_RECORD_STARTED,
2009/10/07 12:41:01.060: u-Event: ADIEVN_RECORD_STARTED,
2009/10/07 12:41:14.700: Record buffer full event: 0
2009/10/07 12:41:14.700: Event: ADIEVN_RECORD_DONE, Voice End , nbytes=218240
2009/10/07 12:41:14.700: Setting system variable '@RECORD_RESULT' to 'SPEECH STOP'
2009/10/07 12:41:14.700: [508] Set Global Variable
2009/10/07 12:41:14.700: Setting global variable '@Q17' to '1'
2009/10/07 12:41:14.700: [867] Clear TT

The resulting .wav file lasts for about 14 seconds and matching what I see above. It appears that the person leaving the message was not quite finished talking. It seems like she was cut off.


On the following call the person also seemed to be talking and was cut off after about 4 seconds.

2009/10/19 17:33:14.110: Modifying value is 'Q17.wav'
2009/10/19 17:33:14.110: @VOXFILE = @VOXFILE CAT Q17.wav
2009/10/19 17:33:14.110: @VOXFILE = D:\Program Files\TeleFlow\Applications\12705\Messages\07091019629323 CAT Q17.wav
2009/10/19 17:33:14.110: Setting global variable '@VOXFILE' to 'D:\Program Files\TeleFlow\Applications\12705\Messages\07091019629323Q17.wav'
2009/10/19 17:33:14.110: [505] Record
2009/10/19 17:33:14.110: Maximum record time is '180000'
2009/10/19 17:33:14.110: Silence TIMEOUT is '4000'
2009/10/19 17:33:14.110: Voice file '@VOXFILE' evaluates to 'D:\Program Files\TeleFlow\Applications\12705\Messages\07091019629323Q17.wav'
2009/10/19 17:33:14.125: Recording 'D:\Program Files\TeleFlow\Applications\12705\Messages\07091019629323Q17.wav'
2009/10/19 17:33:14.407: Event: ADIEVN_RECORD_STARTED,
2009/10/19 17:33:14.407: u-Event: ADIEVN_RECORD_STARTED,
2009/10/19 17:33:18.407: Record buffer full event: 0
2009/10/19 17:33:18.407: Event: ADIEVN_RECORD_DONE, No Voice , nbytes=64160
2009/10/19 17:33:18.407: No voice detected
2009/10/19 17:33:18.407: Setting system variable '@RECORD_RESULT' to 'NO VOICE'
2009/10/19 17:33:18.407: [508] Set Global Variable
2009/10/19 17:33:18.407: Setting global variable '@Q17' to '1'
2009/10/19 17:33:18.407: [867] Clear TT


Interesting to is the Difference in the @RECORD_RESULT of the 2 calls. One is “Speech Stop” and the other is “No Voice”.
I’m trying to figure out if I have a problem or not with the recordings. The no voice and yet having a 4 seconds recording is confusing.
I am running teleflow designer vers 2007.0.5.1234

SPEECH STOP and NO VOICE are very similar in nature, but don't mean the same thing. SPEECH STOP means some speech was heard during the recording, but then none was heard for some period of time (In this case, 4 consecutive seconds). NO VOICE means that no speech was heard from the beginning of the recording through to the end, which is when the timeout of 4 seconds fires. The reason there is a recording with NO VOICE is that silence/noise isn't used to determine when to record, only when to stop recording. So, if the step is run, and there is a call on the line, TeleFlow will record whatever sound the card "hears", including no sound at all.

If both of these recordings have audio in them (and no 4-second gaps in the audio anywhere), it is most likely that the audio is below a certain volume threshold.

If it is possible (I.e. If this doesn't create any sort of problem for you), it would help us to have a copy of one or both of these recordings, to see if there is anything apparent by reviewing the file in a wav form viewer. For this to really be useful, it would also help to know if your application uses either the Set Volume step, or the @VOLUME variable.

Let's start there. If that isn't possible, we'll follow-up with other suggestions.

If you can send the files, email them to support@engenic.com. I will follow-up in this thread.

I have sent the requested files via email.
I also took a look at the application.
The @VOLUME, @REC_VOLUME and @PLAY_VOLUME are all read out of a table. They are all set to 0 and are not referenced after the initial read.
We do not use the set_volume step in the application.

What function does the @VOLUME play during the record step?

I have the files, thank you. They are somewhat quiet(well, one of them is really quiet, and that one is the one that detects as having no audio at all, from beginning to end), although without more information, not necessarily quiet enough to explain why "no speech detection" is kicking in.

I'm going to have to request some more information to investigate further. Can you please provide(send to support@engenic.com):
- One complete .log file that shows a call from Wait for Call (actually, the previous hang up to one call's wait for call would be even better) up to the end of the Record step that has given you grief. It doesn't have to be a log where the problem actually occurs, we are just looking for any clues/hints in the logic of the call.
- From C:\NMS\OAM\cfg: oamsys.cfg
- Open oamsys.cfg, and find all uncommented "File = " lines to determine what board configuration files you are using, and send those as well. These will be in either the C:\NMS\AG\CFG or C:\NMS\CG\CFG directories, depending on the hardware you are currently using.


As for @VOLUME: That variable affects both Play and Record volume, so increasing the variable from 0 to 1, for example, will make all your prompts play louder, and will increase the volume of all recordings. We sometimes increase the value to 1 just prior to a Record step, then put it back to 0 for all subsequent Play steps, so that the resultant audio file is louder. That said, for investigating this issue, having them both at 0 is better. (anything that modifies the volume is only going to confuse our efforts at telling why the card is detecting silence)

The requested information has been sent to support@engenic.com.

I suspect that automatic gain control might be playing a part in our inability to tell "why" the volume of the person on the line is low enough to detect as silence.

Can you uncheck the "Automatic gain control" on your Record step, and run the application that way? We will need to see the next recording (the audio file) that cuts off after this has been put in place to see if that helps explain it. Any NO VOICE or SPEECH STOP terminated recording that appears cut-off will do. Note that you might have to crank the volume on these to hear anything at all in them(if you are listening to them to hear that they are cut off).

The logs and config file might yet provide clues, depending on how this progresses, but at present, there isn't anything there that suggests a problem.

I turned of the automatic gain control as suggested. You are right, The volume level of the recordings is very very very low. It seems to have improved the cut off problem, however it is still occurring, just with less frequency. (I also increased the silence timeout to 6 secs ( 6000 ms))

Here is as example of the log from a recent cutoff. The recording lasted about 22 seconds. The person is still talking at the time it is cutoff.

2009/11/13 18:06:17.925: Base value is 'd:\Program Files\TeleFlow\Applications\12800\Messages\'
2009/11/13 18:06:17.925: Modifying value '@RESPONDENT' evaluates to '24091113650347'
2009/11/13 18:06:17.925: @VOXFILE = d:\Program Files\TeleFlow\Applications\12800\Messages\ CAT @RESPONDENT
2009/11/13 18:06:17.925: @VOXFILE = d:\Program Files\TeleFlow\Applications\12800\Messages\ CAT 24091113650347
2009/11/13 18:06:17.925: Setting global variable '@VOXFILE' to 'd:\Program Files\TeleFlow\Applications\12800\Messages\24091113650347'
2009/11/13 18:06:17.925: [449] Math
2009/11/13 18:06:17.925: Base value '@VOXFILE' evaluates to 'd:\Program Files\TeleFlow\Applications\12800\Messages\24091113650347'
2009/11/13 18:06:17.925: Modifying value is 'Q9.wav'
2009/11/13 18:06:17.925: @VOXFILE = @VOXFILE CAT Q9.wav
2009/11/13 18:06:17.925: @VOXFILE = d:\Program Files\TeleFlow\Applications\12800\Messages\24091113650347 CAT Q9.wav
2009/11/13 18:06:17.925: Setting global variable '@VOXFILE' to 'd:\Program Files\TeleFlow\Applications\12800\Messages\24091113650347Q9.wav'
2009/11/13 18:06:17.925: [417] Record
2009/11/13 18:06:17.925: Maximum record time is '180000'
2009/11/13 18:06:17.925: Silence TIMEOUT is '6000'
2009/11/13 18:06:17.925: Voice file '@VOXFILE' evaluates to 'd:\Program Files\TeleFlow\Applications\12800\Messages\24091113650347Q9.wav'
2009/11/13 18:06:17.925: Recording 'd:\Program Files\TeleFlow\Applications\12800\Messages\24091113650347Q9.wav'
2009/11/13 18:06:18.221: Event: ADIEVN_RECORD_STARTED,
2009/11/13 18:06:18.221: u-Event: ADIEVN_RECORD_STARTED,
2009/11/13 18:06:40.267: Record buffer full event: 0
2009/11/13 18:06:40.267: Event: ADIEVN_RECORD_DONE, Voice End , nbytes=352800
2009/11/13 18:06:40.267: Setting system variable '@RECORD_RESULT' to 'SPEECH STOP'
2009/11/13 18:06:40.267: [423] Set Global Variable


Any other Ideas, thoughts, suggestions?

We are trying to determine if your cut-off problem is directly related to the volume of the speakers who are recording. TeleFlow stops recording if it detects silence. The silence measurement is not an absolute, as there is always some noise on a telephone line. Rather it is defined as anything below a certain threshold.

Please forward a few recording samples to support{at}engenic{dot}com so we can have a look at the audio now that it is not adjusted by automatic gain control.

We received your recent audio samples and had a look at them. This confirms our suspicions. This input audio is below the silence detection threshold. Put bluntly, TeleFlow can't "hear" these callers.

The effect is most pronounced in the first file (04091117492550Q9.wav). The recording is exactly 6 seconds long, the same duration as the silence timeout setting of your Record step. The caller did not exceed the minimum volume at any point during those 6 seconds, and so the system determined that no one was talking.

The second recording (24091113650347Q9.wav) lasted for 22 seconds, and so, only the final 6 seconds are relevant to the problem at hand. At (or very close to) the 16 second mark, the caller's volume dropped below the threshold and stayed there for 6 seconds, causing the system to think she had stopped talking.

Anticipating your next question: what can be done about it? Well, that is tricky. The audio detection algorithm analyzes the samples as they are captured. Any given sample must be louder than a minimal energy value in order to be considered, and then subsequent samples must also be above that value until a minimum duration is reached.

These values are hard-coded at -45 dB for 100 ms. Audio that does not meet this requirement is considered silence. That silence must be present for a duration equal to the silence timeout setting. This value is within the control of the TeleFlow developer, and in your case is 6 seconds.

You could increase your silence timeout; perhaps 10 seconds would work better. I wouldn't bother to set it longer than that. I don't think it would cause a problem, but I doubt it will provide any additional benefit beyond that point.

It is possible to adjust those hard-coded thresholds, although NMS recommends that you use the defaults. I have attached a .TAM file you can try. Put this in your call-flow after the call is answered and before your first Record step. You should only need to call this module once per telephone call. This shouldn't cause any problems in your application, however, is it experimental. I would recommend you make a backup of your application as-is and be prepared to roll-back - just in case!

Also...

Are you getting a lot of these quiet calls? If so, you may want to contact your telecom service provider to check your circuit(s).