# DynamicRecordBuffers

Specifies the maximum number of overflow buffers that the board automatically allocates for recording, when recording is initiated in asynchronous board-to-host data transfer mode (using the adiRecordAsync function).

#### Syntax

DynamicRecordBuffers = buffercount

#### Access

Read/Write

#### Type

Integer

#### Default

0

#### Allowed values

0 - 256

#### Example

DynamicRecordBuffers = 6

#### Details

This mode is often used to transfer data from the board to the host for near-real-time processing (for example, during voice recognition).

By default, when the application invokes adiRecordAsync, the board allocates a single buffer and begins filling it with recorded data. The application immediately invokes adiSubmitRecordBuffer to cause the board to allocate another buffer to fill when the first buffer is full. Whenever the ADI service indicates that a record buffer is full (by returning ADIEVN_RECORD_BUFFER_FULL), the application immediately invokes adiSubmitRecordBuffer again to cause a second buffer to be allocated. Thus at any given time there are two buffers allocated on the board: one being filled (or full, waiting to be sent), and a second one waiting to be filled (or filling).

However, at certain times both buffers can fill before the application has a chance to invoke adiSubmitRecordBuffer again. In this case, data can be lost.

To mitigate this problem, set DynamicRecordBuffers to the number of additional buffers that are automatically allocated by the board when adiRecordAsync is invoked. 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.

Regardless of how a buffer is allocated, it will not be sent to the host until solicited by the host (by invoking adiSubmitRecordBuffer). Each buffer requires a separate request.

The size of the additional buffers is the size of the initial record buffer, requested by invoking adiRecordAsync. DynamicRecordBuffers does nothing unless recording is started with a buffer no larger than Buffers[1].Size. Consequently, additional buffers are allocated from the Buffers[1] buffer pool. All record buffers must be the same size. The final buffer can be smaller.

For example, suppose you set the buffer size to 200 ms (Buffers[1].Size = 1600 for mu-law encoding), and DynamicRecordBuffers = 6. These settings mean that once the first buffer is filled and sent to the host, the host can delay up to 1.4 seconds before requesting more data:

200 ms x (1 initial buffer + 6 additional buffers)

For more information about asynchronous board-to-host recorded data transfer, refer to the Dialogic® NaturalAccess™ Alliance Device Interface API Developer's Manual.

#### See also

Buffers[x].Size