Avoiding underruns when recording

Symptom

When recording asynchronously in voice applications based on Dialogic CG Series Media Boards, the data is supplied to the application using two buffers per port. For proper operation, each buffer must be submitted while the previous buffer is being filled. If a buffer is submitted too late, an underrun occurs and the input data is lost.

Reason for the issue

Typical IVR applications use large buffers to record the users input (e.g. each buffer may contain 2 seconds worth of voice), therefore there is usually enough time to process the incoming buffer and send it back to the board before the next buffer is filled. The board allocates each buffer from one of two buffer pools containing different sized buffers. Buffers[0] is used for "large" buffers, but a buffer will be allocated from Buffers[1] if its size is small enough.

ASR applications usually require much smaller recording buffers (e.g. each buffer may contain 200 ms worth of voice). In this case, especially on heavily loaded systems, two buffers are not enough to avoid underrun conditions.

Workaround

To mitigate this problem, it is possible to allocate additional dynamic buffers on the board. If the two initial buffers fill up, the additional buffers are filled one at a time. If the host falls behind, data is preserved in the additional buffers until the application can catch up. The size of the additional buffers is the size of the initial record buffer requested by invoking the asynchronous recording function. 

Additional buffers are allocated only from the buffer pool named Buffers[1]. Dynamic allocation can occur only when recording is started with a buffer no larger than Buffers[1].Size

The following CG series board keywords are used to configure the board memory allocation when using dynamic overflow buffers.

DynamicRecordBuffers  - Specifies the maximum number of dynamic overflow buffers per port that the board allocates for recording.

Buffers[1].Size  -  Specifies the size of dynamic buffers. 

All record buffers must be the same size (the final buffer can be smaller).
This value should be equal or larger than the buffer size used for the asynchronous recording.

When Dynamic Buffers are used this keyword should be set to:

Max number of ports * ( 2 + number of dynamic buffers ) for non ISDN configurations
Max number of ports * ( 2 + number of dynamic buffers ) + 263 for ISDN configurations

Examples

If buffer size is 1600 (corresponding to 200 ms for m-law or A-law encoding) and DynamicRecordBuffers is 6, the application will be able to use up to 8 buffers per port. This means that once the first buffer is filled and sent to the host, the host has up to 1.4 seconds before requesting more data (200 ms x 7 buffers).

Example for CG Series Boards: 

DynamicRecordBuffers = 6 # Buffers[1].Size = 1600 # 200ms for A-law or mu-law

NOTE

 Once the board is booted, you can check the number and size of buffers in the OAM database using the command oaminfo. 

For example, for board  number 1:

oaminfo -b1 -k Buffers.

You may also check the oam.rpt file to see for example the number of buffers or the amount of free RAM. 

Product List

Dialogic CG Series Media Boards

Glossary of Acronyms / Terms

Automatic Speech Recognition (ASR) -- ASR resources, called ASR engines in the MRCP framework, typically enable users of information systems to speak entries rather than punching numbers on a keypad.