VPB Driver Design V1.0
Created 12/9/99 by David Rowe

Introduction

This document presents some information on the Voice Processing Board (VPB) driver software design. Please feel free to email me (David Rowe) with any questions.

Software Organisation

Figure 1 illustrates the general organisation of the software, the following sections discuss the organisation.

Figure 1: Software Organisation

DSP Firmware

Performs computationally intense signal processing functions such as DTMF detection, echo cancellation, compression and decompression.
Manages real-time scheduling of signal processing functions.
Interfaces VPB hardware to upper layers.
Configuration of signal processing "objects".

Kernal Mode Driver

Provides access to VPB hardware via I/O ports. This needs to be performed by a device driver in most operating systems, as user mode programs have restricted access to I/O ports.
Provides reliable polling of the VPB hardware. One consequence of the VPB design (no interrupts) is that the VPB hardware must be polled regularly (ideally every 20ms, worst case 64-128ms depending on the compression). If it is not polled in time, the signal FIFOs may underflow or overflow, and speech samples may be lost. In the NT version, this regular polling was only possible in a kernal mode driver, due to the poor determinism of user-mode multitasking. Thus the polling, and a layer of FIFO buffering was implemented in the device driver. Under other operating systems, this layer may not be necessary.

VPBAPI

The Voice Processing Board Application Programmers Interface (VPBAPI) implements most of the functionality of the VPB driver and is where most of the code is written. In the current NT version, this is a user mode library. Placing most of the code in user mode makes it easier to work on compared to placing everything in a device driver, however the disadvantage is lack of control over real time issues.

A large number of functions are exported from VPBAPI for use by the application programmer, these are documented exist in a Windows help file (VPB.HLP).

Application

The application uses the functions in VPBAPI to implement the desired functionality, for example Voicemail, VOIP gateway, IVR etc.

VPB Driver Design

Introduction

This section describes the software design of the VPB driver, from the point of view of a logical "programming" model.

Conventions

Up and Down refer to the direction of data flow with respect to the Host PC:

Data flowing Up is moving from the DSP to the PC.
Data flowing Down is moving from the PC to the DSP.

Data Paths

Throughout the software design there are two logical data paths:

Signal data path: used for real time audio data.
Message data path: a low bandwidth path used for everything else.

Examples of message data path usage are:

Configuration of the DSP firmware: The PC can configure firmware by sending messages to the DSP such as "create a DTMF detector", or "connect an A/D to a DTMF detector".
Event passing: The DSP can send messages to the PC such as "ringing on channel 1", or "DTMF digit 0 on channel 3".

Firmware (DSP) Configuration

The Firmware (DSP) signal processing configuration is controlled at run time using an object oriented configuration model, where objects are created, then connected together with software "wires". The signal processing classes available are:

codec A/D and D/A converters.
signal format conversion, for example mu-law to linear, linear to mulaw (A-law, 16-bit linear, Dialogic ADPCM also supported).
DTMF detector.
programmable tone detector (for detecting call progress tones).
programmable tone generator (make your own dial tones, beeps).
line echo canceller (improves DTMF cut-thru, also required for VOIP).

When the VPB boots, the DSP configuration is blank. The PC then sends config messages to create the objects required for signal processing. The configuration for each channel is typically repeated identically for each channel.

Two fundamental limits to the number of objects are:

The computational load (currently 40 MIPs).
The amount of DSP memory (currently 64k x 16-bit). This memory is shared between program and data, configuration objects consume only data as the same program code is used for each object.

Traps (in the form of DSP asserts) are present in the DSP firmware to detect excess consumption of either computational load or memory. These traps will cause an error message to be sent to the PC. Other traps also exist to prevent invalid object configuration.

Note that some of the classes can transmit and receive messages via the message data path. For example, if the DTMF detector detects a digit, it will send a message to the PC. Another example is configuring the programmable tone detector, in this case the PC sends a message defining the tone to a programmable tone detector object.

Figure 2 presents a simple example configuration.

When the program starts, only the Down Message FIFO, Up Message FIFO, and Config. Manager are present. The PC then sends messages instructing the Config manager to create a Codec A/D, A-law to linear, DTMF Detector, and Up Signal FIFO object. The PC then sends messages creating software "wires" to connect these objects appropriately.

Now, when audio arrives over the phone line, it is converted to 16-bit linear format and placed in the Up Signal FIFO. The PC can then read it and perhaps save it to disk (say as a recorded voice mail message). If a DTMF tone is detected, the DTMF detector responds by placing a message in the Up Message FIFO. The PC will subsequently read this and say display it to the screen.