Sophie: vpb2-2.0.4-2mdk i586

vpb2-2.0.4-2mdk.i586.rpm

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   <meta name="Author" content="Voicetronix">
   <meta name="GENERATOR" content="Mozilla/4.51 [en] (Win95; I) [Netscape]">
   <meta name="Description" content="VPB documentation for open source project">
   <title>VPB-DOC-001</title>
</head>
<body>

<center><b><font size=+2>VPB Driver Design V1.0</font></b>
<br><b>Created 12/9/99 by <a href="mailto:voicet@bigpond.com.au">David
Rowe</a></b></center>

<h1>
Introduction</h1>
This document presents some information on the Voice Processing Board (VPB)
driver software design.&nbsp; Please feel free to email me (<b><a href="mailto:voicet@bigpond.com.au">David
Rowe</a></b>) with any questions.
<h1>
Software Organisation</h1>
Figure 1 illustrates the general organisation of the software, the following
sections discuss the organisation.
<p><img SRC="Software_Organisation.JPG" height=287 width=441>
<br><b>Figure 1: Software Organisation</b>
<br>&nbsp;
<h2>
DSP Firmware</h2>

<ul>
<li>
Performs computationally intense signal processing functions such as DTMF
detection, echo cancellation, compression and decompression.</li>

<li>
Manages real-time scheduling of signal processing functions.</li>

<li>
Interfaces VPB hardware to upper layers0.</li>

<li>
Configuration of signal processing "objects".</li>
</ul>

<h2>
Kernal Mode Driver</h2>

<ul>
<li>
Provides access to VPB hardware via I/O ports.&nbsp; This needs to be performed
by a device driver in most operating systems, as user mode programs have
restricted access to I/O ports.</li>

<li>
Provides reliable polling of the VPB hardware.&nbsp; 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).&nbsp;
If it is not polled in time, the signal FIFOs may underflow or overflow,
and speech samples may be lost.&nbsp; In the NT version, this regular polling
was only possible in a kernal mode driver, due to the poor determinism
of user-mode multitasking.&nbsp; Thus the polling, and a layer of FIFO
buffering was implemented in the device driver.&nbsp; Under other operating
systems, this layer may not be necessary.</li>
</ul>

<h2>
VPBAPI</h2>
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.&nbsp; In the current NT version, this is a user mode library.&nbsp;
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.
<p>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).
<h2>
Application</h2>
The application uses the functions in VPBAPI to implement the desired functionality,
for example Voicemail, VOIP gateway, IVR etc.
<h1>
VPB Driver Design</h1>

<h2>
Introduction</h2>
This section describes the software design of the VPB driver, from the
point of view of a logical "programming" model.
<h2>
Conventions</h2>
Up and Down refer to the direction of data flow with respect to the Host
PC:
<ul>
<li>
Data flowing Up is moving from the DSP to the PC.</li>

<li>
Data flowing Down is moving from the PC to the DSP.</li>
</ul>

<h2>
Data Paths</h2>
Throughout the software design there are two logical data paths:
<ul>
<li>
Signal data path: used for real time audio data.</li>

<li>
Message data path: a low bandwidth path used for everything else.</li>
</ul>
Examples of message data path usage are:
<ul>
<li>
Configuration of the DSP firmware:&nbsp; 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".</li>

<li>
Event passing:&nbsp; The DSP can send messages to the PC such as "ringing
on channel 1", or "DTMF digit 0 on channel 3".</li>
</ul>

<h2>
Firmware (DSP) Configuration</h2>
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".&nbsp; The signal processing
classes available are:
<ul>
<li>
codec A/D and D/A converters.</li>

<li>
signal format conversion, for example mu-law to linear, linear to mulaw
(A-law, 16-bit linear, Dialogic ADPCM also supported).</li>

<li>
DTMF detector.</li>

<li>
programmable tone detector (for detecting call progress tones).</li>

<li>
programmable tone generator (make your own dial tones, beeps).</li>

<li>
line echo canceller (improves DTMF cut-thru, also required for VOIP).</li>
</ul>
When the VPB boots, the DSP configuration is blank.&nbsp; The PC then sends
config messages to create the objects required for signal processing.&nbsp;
The configuration for each channel is typically repeated identically for
each channel.
<p>Two fundamental limits to the number of objects are:
<ul>
<li>
The computational load (currently 40 MIPs).</li>

<li>
The amount of DSP memory (currently 64k x 16-bit).&nbsp; This memory is
shared between program and data, configuration objects consume only data
as the same program code is used for each object.</li>
</ul>
Traps (in the form of DSP asserts) are present in the DSP firmware to detect
excess consumption of either computational load or memory.&nbsp; These
traps will cause an error message to be sent to the PC.&nbsp; Other traps
also exist to prevent invalid object configuration.
<p>Note that some of the classes can transmit and receive messages via
the message data path.&nbsp; For example, if the DTMF detector detects
a digit, it will send a message to the PC.&nbsp; 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.
<p>Figure 2 presents a simple example configuration.
<br><img SRC="Configuration_Example.JPG" height=347 width=741>
<br>When the program starts, only the Down Message FIFO, Up Message FIFO,
and Config. Manager are present.&nbsp; 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.&nbsp; The PC then sends messages creating software
"wires" to connect these objects appropriately.
<p>Now, when audio arrives over the phone line, it is converted to 16-bit
linear format and placed in the Up Signal FIFO.&nbsp; The PC can then read
it and perhaps save it to disk (say as a recorded voice mail message).&nbsp;
If a DTMF tone is detected, the DTMF detector responds by placing a message
in the Up Message FIFO.&nbsp; The PC will subsequently read this and say
display it to the screen.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
</body>
</html>