BitSophia - BitVoicer Server 1.0 User’s ...23 Inactivity Timeout: .

BitSophia - www.bitsophia.com BitVoicer Server 1.0 – User’s Manual - English

Copyright © 2015 BitSophia Tecnologia Ltda - ME. All rights reserved. 1

BitVoicer Server 1.0

User’s Manual

English

http://www.bitsophia.com/



Contents 1 Introduction ........................................................................................................................................... 5

1.1 Minimum Requirements ................................................................................................................ 5

1.2 Installation .................................................................................................................................... 5

1.3 Safety Warning ............................................................................................................................. 5

2 Product Overview.................................................................................................................................. 6

2.1 Communication............................................................................................................................. 6

2.2 BitVoicer Server Solution .............................................................................................................. 8

2.3 Application Package ..................................................................................................................... 8

2.4 Licensing ...................................................................................................................................... 8

2.5 Languages ................................................................................................................................... 9

3 BitVoicer Server Details .......................................................................................................................10

3.1 Server Modules ...........................................................................................................................10

3.1.1 Solution ...................................................................................................................................11

3.1.2 Communication Manager .........................................................................................................11

3.1.3 Speech Manager .....................................................................................................................11

3.1.4 Command Shooter ...................................................................................................................14

3.1.5 Data Forwarding ......................................................................................................................14

4 BitVoicer Server Manager ....................................................................................................................16

4.1 Solution Objects ..........................................................................................................................18

4.1.1 Locations .................................................................................................................................18

4.1.2 Devices ...................................................................................................................................19

4.1.3 Binary Data ..............................................................................................................................25

4.1.4 Voice Schemas ........................................................................................................................26

4.1.5 Commands ..............................................................................................................................30

4.2 Server Properties .........................................................................................................................33

4.2.1 Speech ....................................................................................................................................33

4.2.2 Communication ........................................................................................................................35

4.2.3 Log ..........................................................................................................................................36

4.3 Manager Options .........................................................................................................................36

4.4 Server Log ...................................................................................................................................37

4.5 Server Monitor .............................................................................................................................38

4.5.1 General ...................................................................................................................................39

4.5.2 Communication ........................................................................................................................39

4.5.3 Data Forwarding ......................................................................................................................40

4.5.4 Speech ....................................................................................................................................41

4.6 Exporting Solution Objects ...........................................................................................................42

4.7 Importing Solution Objects ...........................................................................................................44

4.7.1 Importing Voice Schemas and Commands ...............................................................................45




4.7.2 Importing Voice Schemas Only ................................................................................................47

4.7.3 Importing Devices ....................................................................................................................49

4.7.4 Importing Binary Data ..............................................................................................................53

4.8 Speech Recognition and Synthesis Trials ....................................................................................54

4.9 Activation.....................................................................................................................................56

5 BitVoicer Server UI Link .......................................................................................................................57

6 BitVoicer Server Protocol .....................................................................................................................59

6.1 Definitions ...................................................................................................................................59

6.2 Scope ..........................................................................................................................................60

6.3 Basic Concepts............................................................................................................................60

6.3.1 Framed Mode ..........................................................................................................................60

6.3.2 Stream Mode ...........................................................................................................................60

6.3.3 Speech Recognition Engine .....................................................................................................60

6.4 Communication Interfaces ...........................................................................................................60

6.4.1 TCP/IP .....................................................................................................................................60

6.4.2 Serial Port ................................................................................................................................61

6.5 Operational Description ...............................................................................................................61

6.5.1 Initial Operating Mode ..............................................................................................................61

6.5.2 Changing the Operating Mode .................................................................................................62

6.5.3 Requesting Server Status ........................................................................................................62

6.5.4 Speech Recognition .................................................................................................................62

6.5.5 Forwarding Data to Applications on the Server .........................................................................62

6.5.6 Receiving Typified Data from the Server ..................................................................................63

6.6 BitVoicer Server Protocol Frame Structure ...................................................................................63

6.6.1 Fields of the Frame ..................................................................................................................64

6.7 Notes...........................................................................................................................................65

6.8 Open Specifications .....................................................................................................................65

7 Library References ...............................................................................................................................66

7.1 C# Library ....................................................................................................................................66

7.1.1 BitSophia.BitVoicerServer.Integration ......................................................................................66

7.1.2 BitSophia.BitVoicerServer.Integration.SpeechInterfaceService .................................................81

7.1.3 BitSophia.BitVoicerServer.Integration.DataFwdService ............................................................92

7.2 Arduino Libraries .......................................................................................................................103

7.2.1 BVSP.....................................................................................................................................103

7.2.2 BVSMic .................................................................................................................................113

7.2.3 BVSSpeaker ..........................................................................................................................116

8 Examples ...........................................................................................................................................119

8.1 Getting the Server Status ...........................................................................................................119

8.1.1 Required Material ..................................................................................................................119

8.1.2 Step-by-Step..........................................................................................................................119




8.2 Implementing Speech Recognition .............................................................................................121


8.2.2 Step-by-Step..........................................................................................................................122

8.3 Implementing Speech Recognition and Synthesis ......................................................................127


8.3.2 Step-by-Step..........................................................................................................................127

8.4 Using the Data Forwarding Module ............................................................................................135


8.4.2 Step-by-Step..........................................................................................................................135

8.5 Using the Server Audio Adapter .................................................................................................137


8.5.2 Step-by-Step..........................................................................................................................137




1 Introduction

This document describes all components of the BitVoicer Server speech automation platform.

Among the covered topics are:

The objects that comprise a BitVoicer Server solution;

The server modules and how they interact;

How the BitVoicer Server Manager works;

The specifications of the BitVoicer Server Protocol;

The integration of client devices with the server;

The integration API documentation;

Implementation examples.

1.1 Minimum Requirements

Operating system: Windows Vista, 7, 8 or 10 (except Windows 10 IoT Core and Windows 10 Mobile)

Microsoft .NET Framework 4.0 or later

Internet connection (for the activation and installation of additional languages)

Audio adapter

Regular or virtual serial port (for serial communication)

Network adapter (for TCP/IP communication)

1.2 Installation

To perform the following installation procedures, you must use a Windows account with administrator

privileges:

1) Before you begin the BitVoicer Server installation, make sure the computer has the Microsoft .Net

Framework 4 installed. To verify if this framework is installed, click on Start Control Panel

Programs Programs and Resources. If the Microsoft .Net Framework 4 is not listed, download

(http://www.microsoft.com/en-us/download/details.aspx?id=17851) and install this framework before

proceeding.

2) Make sure that the computer audio adapter is enabled and its drivers are updated.

3) Download the right installation package for your operating system (32-bits or 64-bits) at

http://www.bitsophia.com/en-US/BitVoicerServer/Downloads.aspx. To determine which Windows

version is installed on your computer, click on Start Control Panel System and Security

System and check the description in System type.

4) Run the BitVoicer Server installation package and grant permission for the installation to proceed.

5) Follow the steps in the installation wizard.

1.3 Safety Warning

BitVoicer Server must not be used in any mission critical applications, life support devices, the

conduction or operation of machinery or automotive vehicles, or, any application whose malfunction can

cause damage to people, property, or the environment or endanger the health of persons or animals.

BitSophia does not authorize the use of its software in any of these applications. The user assumes all

liability for any misuse of BitVoicer Server or violation of this warning.


http://www.microsoft.com/en-us/download/details.aspx?id=17851

http://www.bitsophia.com/en-US/BitVoicerServer/Downloads.aspx



2 Product Overview

BitVoicer Server is a speech recognition and synthesis server for speech automation. It was

developed to enable simple devices, with low processing power, to become voice-operated.

In general, the architecture of a BitVoicer Server automation solution is comprised of the server,

input devices and output devices.

Input devices are responsible for capturing, digitalizing and sending audio streams to the server. The

server, in turn, processes these audio streams, recognizes the sentences present in the stream and maps

them to commands that will be sent to output devices.

In addition to input and output devices, BitVoicer Server can also serve mixed devices, which are

capable of acting as input and output devices, and the server audio adapter.

2.1 Communication

Two communication interfaces are available for client devices to establish communication with

BitVoicer Server: serial and TCP/IP. Virtual serial ports, such as those created by Bluetooth and USB/Serial

adapters, are also supported. These adapters enable BitVoicer Server to send commands to devices that

use other communication protocols (e.g. Z-Wave and X10).

The standard communication protocol between BitVoicer Server and client devices is the BitVoicer

Server Protocol. This is a proprietary protocol of BitSophia Tecnologia Ltda - ME, although all technical

specifications regarding its implementation are described in section 6 BitVoicer Server Protocol.

BitVoicer Server can also interact with other application running on the server through Windows

Communication Foundation (WCF) services. The WCF services exposed by the server use Web Service


https://msdn.microsoft.com/en-us/library/dd456779(v=vs.100).aspx


http://en.wikipedia.org/wiki/List_of_web_service_specifications



(WS) specifications that enable the integration with a variety of development platforms (e.g. .Net, Java and

Delphi). In case of .Net development, there is also the option of using the integration library described in

section 7.1 C# Library.


http://en.wikipedia.org/wiki/List_of_web_service_specifications



2.2 BitVoicer Server Solution

In order to define the BitVoicer Server client devices, where they are located, which voice commands

must be recognized and what must be done when recognitions are validated, the user must create items that

describe all entities involved in this structure. These items are called objects, and they are stored in a file

named BitVoicer Server Solution.

The objects in a BitVoicer Server Solution are structured using the same concepts that are applied to

relational databases. By making an analogy between these concepts and the solution objects, we can say

that types of objects (i.e. locations, devices, binary data, commands and Voice Schemas) in a solution are

similar to tables in a database and the objects themselves are similar to records in these tables.

In the same way that relational databases usually enforce referential integrity between records,

BitVoicer Server also does it between solution objects. For example, it is not possible to remove a location

that has been assigned to a device or to associate a command with an invalid Voice Schema.

All objects in a BitVoicer Server Solution are created, edited and removed using the BitVoicer Server

Manager. This application enables solution objects to be managed through a graphic interface that also

enforces referential integrity between objects.

The BitVoicer Server Solution is described in details in section 4.1 Solution Objects.

2.3 Application Package

BitVoicer Server is executed as a Windows Service and is initialized with the operating system.

Windows Services are long-running processes that keep running while the computer is on and that should

not have access to the user interface. In order to manage BitVoicer Server and have access to the user

interface resources (microphone and speakers), two applications are used:

BitVoicer Server Manager: This application enables the user to:

o Manage the server properties;

o Add, edit and remove solution objects;

o Monitor the server status;

o View log records;

o Check the status of client devices;

o Follow speech recognition results;

o Exchange information with client devices.

BitVoicer Server UI Link: This application is responsible for:

o Initializing other applications (requested by the server);

o Playing audio files;

o Capturing and synthesizing speech through the system microphone and speaker.

2.4 Licensing

BitVoicer Server licenses are provided on a per-computer per-input device basis. Each input device

must have an activated product key so that one speech recognition engine can be assigned to the device.

Once a product key is activated on a specific computer, it is not possible to transfer or use this product key

on another computer.

For licensing purposes, an input device is the one capable of capturing audio and sending it to the

server for recognition. Input devices include: microphones connected to the server audio adapter and mixed

devices (capable of acting as input and output devices). For a detailed description of input devices, refer to

the section 6.1 Definitions.

Output devices and speakers connected to the server audio adapter do not require licensing in

BitVoicer Server 1.0. Also, there are no limitations regarding the maximum number of output devices that

can be connected to the server.


http://en.wikipedia.org/wiki/Referential_integrity



2.5 Languages

BitVoicer Server is able to perform speech recognition and synthesis in 17 languages:

Catalan

Chinese (China, Honk Kong and Taiwan)

Danish (Denmark)

Dutch (Netherlands)

English (Australia, Canada, India, United Kingdom and United States)

Finnish (Finland)

French (Canada and France)

German (Germany)

Italian (Italy)

Japanese (Japan)

Korean (Korea)

Norwegian, Bokmål (Norway)

Polish (Poland)

Portuguese (Brazil and Portugal)

Russian (Russia)

Spanish (Mexico and Spain)

Swedish (Sweden)




3 BitVoicer Server Details

BitVoicer Server is a speech recognition and synthesis server for speech automation. It was

developed to enable simple devices, with low processing power, to become voice-operated.

Although it is a server, BitVoicer Server consumes few hardware resources and in most scenarios it

does not require an exclusive computer. The table below shows the consumption of server resources while

three input devices are being served. In other words, three speech recognition engines are running to

support these devices:

Computer CPU avg. (%) RAM avg. (MB)

Intel Core i5 2.4GHz / 4GB RAM / Windows 7 64-bits 2.55 116

Intel Core i3 2.1GHz / 4GB RAM / Windows 7 64-bits 3.60 104

Intel Atom 1.66GHz / 1GB RAM / Windows 7 32-bits 7.07 74

It is important to mention that the consumption of CPU and RAM varies as a function of the number

of connected devices and the size of the Voice Schemas present in the solution.

In addition to the low hardware consumption, BitVoicer Server is executed as a Windows Service

and is not visible on the desktop. This allows the computer where the server is installed to be used normally

without interfering with the user interface.

3.1 Server Modules

BitVoicer Server is comprised of five interdependent modules: Solution, Communication Manager,

Speech Manager, Command Shooter and Data Forwarding.




3.1.1 Solution

The Solution Module is responsible for storing, managing and validating the objects that compose a

BitVoicer Server Solution. This module can only be accessed by the user through the object editors available

in the BitVoicer Server Manager. All operations (add, edit, exclude, import and export) performed on solution

objects are validated by the Solution Module that also alters the solution resident in memory and on disk,

and notifies the other running modules about the changes. These modules, in turn, take the appropriate

measures to contemplate the changes and continue execution.

3.1.2 Communication Manager

The Communication Manager Module is one of the most important and more active modules of

BitVoicer Server. The main functions of this module are:

Implement the BitVoicer Server Protocol (BVSP);

Monitor the presence of client device serial ports;

Authorize and establish TCP/IP connections requested by client devices;

Check if the communication interfaces of connected devices are still available and active;

Forward audio streams from the communication interfaces to the Speech Manager Module, and

vice-versa;

Forward data from the communication interfaces to the Data Forwarding Module, and vice-versa;

Forward data from the Command Shooter Module to client devices;

Control the data rate in outbound communication;

Provide server status information to client devices.

For details about the communication interfaces supported by the Communication Manager, refer to

section 6.4 Communication Interfaces.

3.1.3 Speech Manager

The Speech Manager Module is responsible for processing audio streams and performing speech

recognition. When the Communication Manager identifies the presence of an input device, it notifies the

Speech Manager. The Speech Manager then builds and assigns an exclusive Speech Recognition Engine

(SRE) to the device. As soon as the SRE is assigned, it starts processing audio streams sent from the client

device.

While processing audio streams, a SRE can identify multiple recognition hypotheses. These

hypotheses are validated against filters defined in the solution (section 3.1.3.2 Validation Filters) and if one

hypothesis is accepted, the Speech Manager creates the set of commands (section 4.1.5 Commands) that

will be executed by the Command Shooter Module.

In case there is more than one input device installed at the same location (section 4.1.1 Locations)

and they both lead to a valid recognition, the Speech Manager uses a conflict resolution mechanism to

determine which one is valid. This mechanism consists in comparing the recognition results achieved at that

location within a time interval defined in the server properties. The result that has the higher confidence level

within that interval is considered valid and the other recognitions are discarded.

In addition to speech recognition, the Speech Manager Module is also responsible for synthesizing

speech. This module is capable of synthesizing speech upon external application requests or in response to

valid speech recognitions. The synthesized speech can be played by the server audio adapter through the

BitVoicer Server UI Link, or it can be sent as audio stream to client devices.




3.1.3.1 Speech Recognition Engine Assignment

For the Speech Manager to be able to assign SREs to client devices there must be available

licenses for these devices (section 2.4 Licensing). If the solution contains a SystemMic device (section 4.1.2

Devices), it will be the first one to receive a SRE. The assignment order for the other devices cannot be

determined. SREs are assigned in the order in which the Communication Manager identifies the presence of

input devices. In the case of serial devices, it is up to Windows to identify the presence of their ports. In the

case of TCP/IP connections, the first devices to request for connections will be the first ones to receive a

SRE.

3.1.3.2 Validation Filters

To improve the accuracy of SREs, BitVoicer Server uses a series of user-defined Validation Filters.

Only those recognitions that satisfy the criteria defined in the filters are considered valid.

The Validation Filters are applied in the order below. If a recognition result does not pass one of the

filters, the remaining filters are not evaluated and the recognition is rejected:

1) Minimum Confidence Level: Represents the relative minimum probability for the SRE to accept a

recognized speech. The confidence level does not indicate the absolute probability that an

alternative corresponds to a given speech. The confidence level indicates that the alternative is more

likely to be the correct match among the multiple alternatives available in the Voice Schema.

2) Minimum Audio Level: While processing audio streams, the SREs periodically measure the volume

level of the captured audio and calculate the average level from the last measurements. The

minimum audio level is comprised of this average plus the value defined in this filter. To be

considered valid, the audio level during the speech must reach or exceed the minimum audio level

(see picture below). When this level is reached, the audio-level-activated period starts.

3) Audio-level-activated Period: This period, measured in milliseconds, starts when the minimum

audio level is reached. During this period the minimum audio level does not need to be reached

again for a speech to be considered valid. Recognitions performed outside this period are rejected.

4) Latency Period: This period, measured in milliseconds, starts right after a valid recognition.

Recognitions performed inside this period are rejected.

5) Activation Word: It is one word, or a set of words, that must be said before the sentence itself. You

can say the activation word and the sentence in a continuous manner or you can say only the

activation word and, in the activated period, the sentence itself.

6) Activation-word-activated Period: This period, measured in seconds, starts right after an

activation word is recognized. If no activation word has been defined in the Voice Schemas or in the

server properties, the counting of this period is not performed. If one or more activation words have

been defined, only recognitions performed inside this period are considered valid.

7) Conflict Resolution: This filter is only applied if more than one active input device is present at the

same location (section 4.1.1 Locations). It consists in waiting a certain amount of time, measured in

milliseconds, after a valid speech recognition. If another recognition occurs at the same location

within this period, only the one with higher confidence level is considered valid.

8) Location Specific: This filter is defined in the commands present in Voice Schemas (section 4.1.4

Voice Schemas). If a command is set as location-specific, it will only be executed if the device that

captured the audio is at the same location (section 4.1.1 Locations) as the target device of the

command.




The Validation Filters can be set in various solution objects or in the server properties. Those set in

the server properties override the filters set in all solution objects (details in section 4.2 Server Properties).

3.1.3.3 Audio Stream Absence Periods

Input devices may, eventually, need to run other tasks that require intensive use of the

microcontroller resources. In this situation, it may be necessary to stop the audio capture and transfer. The

Speech Manager Module is able to handle these periods and resume speech recognition as soon as new

audio streams arrive. However, it is recommended in this scenario that the input device alter the operating

mode of the channel to framed (section 6.5.2 Changing the Operating Mode) before stopping the transfer of

audio streams. This procedure makes BitVoicer Server release more quickly the resources allocated to

inactive SREs.

3.1.3.4 Synthesized Speech

BitVoicer Server is also capable of synthesizing speech in response to valid recognitions or at

external application requests. The synthesized speech can be reproduced through the server audio adapter

or sent to client devices. The format of the synthesized audio is 8-bit Pulse-code Modulation (PCM) at a

sample rate of 8000 Hz, as defined by the BitVoicer Server Protocol (section 6.3.2 Stream Mode).

The Speech Manager Module is responsible for creating and managing the synthesizers that will

serve client devices and external applications.


http://en.wikipedia.org/wiki/Pulse-code_modulation



3.1.3.5 Speech Manager WCF Service

The Speech Manager Module exposes a Windows Communication Foundation (WCF) service that

enables external application to interact with the features available in this module. This service uses

WSHttpBinding (WCF bindings) and it is exposed at the following addresses:

Service address: http://localhost:[port]/BitSophia/BitVoicerServer/SpeechInterface/SpeechInterface

Infrastructure address that provides service metadata:

http://localhost:[port]/BitSophia/BitVoicerServer/SpeechInterface/SpeechInterface/mex

The [port] field in the address above is defined in the server properties and its default value is 4195.

To get information about the C# Library that encapsulates this service, its objects and available

operations, refer to section 7.1 C# Library.

3.1.4 Command Shooter

The Command Shooter Module is responsible for the execution of the commands defined in Voice

Schemas (section 4.1.4 Voice Schemas).

When the Speech Manager Module identifies a valid speech recognition, it creates the set of

commands associated with that recognition and passes it to the Command Shooter. The Command Shooter,

in turn, executes these commands with respect to the order defined in the Voice Schema and the delays

defined in the commands.

The Voice Schemas in a BitVoicer Server Solution support three types of commands and each one

of them is handled differently by the Command Shooter:

RunExecutable: To run these commands, the Command Shooter needs the support provided by

the BitVoicer Server UI Link because command execution may require interaction with the user

interface. In addition to running executables, with parameters or not, these commands can also open

documents as long as a default editor for the file has been defined in Windows.

PlayAudio: The audio reproduced by these commands can be a .wav file or synthesized speech. In

both cases, the action taken by the Command Shooter depends on the type of the device that is the

target of the command:

o SystemSpeaker devices: The BitVoicer Server UI Link application plays the .wav file or the

synthesized speech defined in the command.

o Output or Mixed devices: The Command Shooter sends the audio samples present in the

.wav file to the client device through the Communication Manager Module or it requests the

Speech Manager to synthesize the speech defined in the command and sends it to the client

device through the Communication Manager Module.

SendData: The Command Shooter wraps the data defined in the command into a frame of the

BitVoicer Server Protocol (section 6.6 BitVoicer Server Protocol) and sends it to the client device

through the Communication Manager Module.

3.1.5 Data Forwarding

The Data Forwarding Module enables external applications to send and receive data from devices

connected to BitVoicer Server. This feature is especially useful for input or mixed devices that use serial

ports as a communication interface because the server keeps their serial ports blocked so that audio

streams can be received from the device.

Although the usefulness of this module is more evident for serial devices, external application can

simplify the communication with TCP/IP devices through the Data Forwarding Module. By using this module

to get connected with client devices, the developer delegates to the server the maintenance of the

connection, avoids direct socket manipulation and does not have to define standards to wrap and transmit

data.



https://msdn.microsoft.com/en-us/library/ms731092(v=vs.100).aspx



The Data Forwarding Module exposes a Windows Communication Foundation (WCF) Service that

enables external application to interact with the features available in this module. This service uses

WSHttpBinding (WCF bindings) and it is exposed at the following addresses:

Service address: http://localhost:[port]/BitSophia/BitVoicerServer/DataForwarding/DataForwarding

Infrastructure address that provides service metadata:

http://localhost:[port]/BitSophia/BitVoicerServer/DataForwarding/DataForwarding/mex

The [port] field in the address above is defined in the server properties and its default value is 4195.

To get information about the C# library that encapsulates this service, its objects and available

operations, refer to section 7.1 C# Library.



https://msdn.microsoft.com/en-us/library/ms731092(v=vs.100).aspx



4 BitVoicer Server Manager

The BitVoicer Server Manager (BVSM) enables the user to manage all resources available in

BitVoicer Server. Through this application it is possible to:

Add, edit and remove solution objects;

Perform speech recognition and communication tests;

Import and export solution objects;

Start and stop the server;

View event logs;

Monitor the status of client devices;

Change the server properties.

The BVSM graphic interface is divided into four basic areas: Main Menu, Toolbar, Object Explorer

and Edit Area. The picture below shows the layout of these areas on the screen:

Main menu: Provides access to tools to add solution objects, activation, help, evaluation,

monitoring, importing and exporting.

Toolbar: Provides quick access to the most used tools. To see their functions, hover the mouse over

the toolbar buttons for a couple of seconds.

Object Explorer: Enables the user to control the BitVoicer Server execution (start or stop) and

provides access to the server properties and main solution objects.




Adjustable Splitter: Enables the user to adjust the width of the Object Explorer and the Edit Area.

Edit Area: This area shows the solution objects being edited.

The Object Explorer offers a few context menus for solution object manipulation and accessing of

server features and properties. In order to access these context menus, you must right-click on the desired

item. The picture below shows the context menu that is shown when you right-click on the BitVoicer Server

item.

This context menu allows the user to start and stop the Windows Service that runs BitVoicer Server,

access the server properties and refresh the solution objects shown in the Object Explorer. The Refresh

feature is available in different tools throughout the BVSM. This feature is often used because when solution

objects are saved, they are updated on the server, but the tools in the manager do not constantly query the

server to update what is shown on screen. For example, creating a location does not make it appear in the

Object Explorer. You must refresh the Locations item so that the new location becomes listed in the object

tree.

The context menus below are shown when you right-click on objects or categories of objects:

These menus allow the user to add, edit or remove solution objects and refresh the objects shown in

any particular category.

The Edit Area, located to the right of the Object Explorer, organizes the opened objects through tabs

that can be selected to show the desired object. In case there are many opened objects, you can show a list

of all opened objects by clicking on the arrow-shaped icon located on the top-right corner of the Edit Area.




4.1 Solution Objects

The BitVoicer Server Solution is structured through the creation and association of various objects.

The main solution objects are shown in the Object Explorer: Locations, Devices, Binary Data and Voice

Schemas. The secondary objects are Device Nodes, Sentence Blocks, Sentence Items, Anagrams and

Commands. These objects are accessed through the edit of the main objects. The diagram below (Class

diagram) shows all of these objects and the relation between them:

4.1.1 Locations

Locations represent the physical location where a device is installed. This solution object is

especially relevant in large installations such as residences or offices with multiple rooms and fixed devices.

On the other hand, the location concept is usually not relevant for mobile machines or devices, even those

with more than one point of capture. However, all solution devices in a BitVoicer Server Solution must be

associated with one location. In the case of mobile machines or devices, a location that represents the

device itself can be used to associate the device with a location.


http://en.wikipedia.org/wiki/Class_diagram

http://en.wikipedia.org/wiki/Class_diagram



There are three ways of creating location objects: through the main menu (File New Location);

through the New Location button ( ) in the toolbar; and through the context menu of the Locations

category in the Object Explorer.

The location form is the simplest form in a BitVoicer Server Solution. The picture below shows all

fields present in this form and, next to it, a description of each field:

ID: Identification number of the object. This number is automatically generated by the server when

the object is added to the solution. It is not possible to change this field.

Name: Description given by the user to the object. We recommend the use of CamelCase notation

for naming (e.g. LivingRoom, Room1, Room2, etc.).

Disable: Indicates whether the location is disabled. When a location is disabled, it is still visible

throughout the manager. However, all devices associated with this location are ignored by the server

as if they were also disabled. In other words, they are not identified by the Communication Manager

and become invisible to the Command Shooter.

4.1.2 Devices

Devices are the BitVoicer Server clients. As defined by the BitVoicer Server Protocol (section 6.1

Definitions) a device is: the “group of hardware and possibly software, comprised of one or more integrated

circuits or MCUs, accompanied by other components or not, capable of accessing the services of the server

through a communication interface.”

There are three ways of creating device objects: through the main menu (File New Device);

through the New Device button ( ) in the toolbar; and through the context menu of the Devices category in

the Object Explorer.

The following topics describe the tabs within the device form and all of its fields.

4.1.2.1 General

The General tab contains various device settings. The picture below shows all fields present in this

tab and, next to it, a description of each field:


http://en.wikipedia.org/wiki/CamelCase






for naming (e.g. ArduinoSerialMic, MicrochipTCPIPSpeaker, ZWaveUSBStick, SystemSpeaker,

etc.). We also recommend that the device name contain at least: the maker or developer of the

device; and its function or model. It helps identifying the devices in the different tools where they are

visualized.

Type: In addition to the device types defined by the BitVoicer Server Protocol (Input, Output and

Mixed), there are also the SystemMic and SystemSpeaker devices. Only one SystemMic device and

one SystemSpeaker device can be added to a solution. SystemMic and SystemSpeaker devices are

treated, respectively, as input and output devices.

Serial Number: This field contains the universal exclusive identification of the device and must be

filled by the user. This serial number is used, mainly, for external applications to exchange data with

client devices through the Data Forwarding Module (section 3.1.5 Data Forwarding). In future

versions, this field will also be used by external installers. The serial number field must be 20

characters long and have the following structure:

o Character 1 to 9: maker or developer ID

o Character 10 to 12: model or version ID

o Character 13 to 20: serial number

Microphone Level: This field is available for changes only when the device type is SytemMic. The

value (1 to 100) set in this field represents the level to be selected in the Windows settings when the

microphone of the server is used to capture audio. This setting will be updated in the operating

system every time a SRE is assigned (section 3.1.3.1 Speech Recognition Engine Assignment) to

the device.

Speaker Level: This field is available for changes only when the device type is SytemSpeaker. The

value (1 to 100) set in this field represents the level to be selected in the Windows settings when the





speakers of the server are used to reproduce audio. This setting will be updated in the operating

system every time audio is played by the server audio adapter.

Synthesizer Volume: This field is available for changes only when the device type is Output, Mixed

or SystemSpeaker. The value (1 to 100) set in this field defines the volume of the audio generated

by the synthesizer when synthesized speech must be sent to the device.

Minimum Audio Level: This field is available for changes only when the device type is Input, Mixed

or SystemMic. It is one of the Validation Filters (section 3.1.3.2 Validation Filters) used by SREs to

determine whether a speech recognition is valid. The purpose of this filter is to reject speech sources

with low intensity and the general rule to set its value is: the more sensitive the capture device, the

higher must be the minimum audio level. The Server Monitor Tool provides real-time information

about the audio levels of input devices and can be used to determine the value of this field.

Location: Physical location where the device is installed. If a newly added location is not visible in

the list box, make sure it has been saved and click on the Refresh button located to the right of the

field.

Disable: Indicates whether the device is disabled. When a device is disabled, it is still visible

throughout the manager. However, disabled devices are not identified by the Communication

Manager and become invisible to the Command Shooter.

WARNING: Every time BitVoicer Server sends audio to the server audio adapter, the audio level in

the Windows settings are adjusted to the level specified in Speaker Level. In case the computer that runs

BitVoicer Server is also used to listen to music, the audio being played will also be adjusted. If the level

specified in Speaker Level is higher than 30, you may experience auditory discomfort especially during the

use of headphones.

4.1.2.2 Communication

The Communication tab contains configurations used by Input, Output and Mixed devices to

exchange data with BitVoicer Server. When the device type is SystemMic or SystemSpeaker, the fields in

this tab remain blocked.

The picture below shows all fields present in this tab and, next to it, a description of each field:




Serial or TCP/IP Interface: These radio buttons allow the selection of the communication interface

used by the device. When one of them is selected, the fields related to the interface are enabled for

editing.

Port Name: The names of serial ports are defined by Windows. Regular serial ports (usually

associated with UART modules present in the computer hardware) keep their names unchanged no

matter which device is connected to the port. On the other hand, virtual serial ports (USB-to-serial)

are created by the operating system when devices that require them are connected to the USB port.

Windows tries to keep their names unchanged when the same device is connected to the same USB

port. The names of serial ports are comprised of “COM” plus the number given to the port (e.g.

COM3, COM4, COM100, etc.).

Baud, Data Bits, Parity, Stop Bits and Flow Control: These settings vary from device to device

and its values must be found in the hardware documentation.

RTS and DTR: Some devices (e.g. Arduino Micro and Arduino Leonardo) use RTS (Request to

Send) and DTR (Data Terminal Ready) signals in the serial port. Refer to the hardware

documentation and enable these fields as required.

Do Not Lock Port: When this option is selected, BitVoicer Server will block the port only when data

must be sent to the device. In the rest of the time, the port remains available so that other

applications can access it. You can select this option only for Output devices because Input and

Mixed devices must be connected to the server constantly in order to send audio streams.

IP Address: If the device uses a TCP/IP communication interface, the IP address of the device must

be specified so that BitVoicer Server can identify the device. To avoid communication issues, we

recommend the use of static IP addresses, although routers that implement dynamic IP services

usually try to assign the same IP address to the same MAC address.


http://en.wikipedia.org/wiki/MAC_address



Inactivity Timeout: This field defines how long , in seconds, a TCP/IP connection can remain

inactive (no data exchange) before all resources associated with it, including SREs, are discarded

and the connection is closed. If a client device loses connection with BitVoicer Server and it is

unable to inform the server about the imminent end of the connection, BitVoicer Server will keep the

TCP/IP socket associated with the connection in an opened state for the period specified in this field.

During this period, the client device will be unable to establish a new connection with the server

because there will be an opened connection using that same IP address. Only when the inactivity

period expires and the server closes and discards the connection, will the client device be able to

establish a new connection with the server.

Data Rate: This field defines the maximum number of bytes per second BitVoicer Server can send

to client devices. This feature is especially useful when audio streams must be sent to devices with

low memory capacity because it can prevent buffer overflows. The value specified in this field must

be consistent with the consumption capacity of the client device. The data rate effectively achieved is

limited to the capacity of the communication interface in use.

MSSS (Maximum Stream Segment Size): It defines the maximum size (in bytes) of the binary

segments sent from BitVoicer Server in each sending operation. If the total number of bytes to be

sent is greater than the MSSS, bytes are dived into segments and sent in regular intervals. This

interval is defined as a function of the value defined in the Data Rate field and the MSSS field. The

MSSS value must be consistent with the size of the input buffer of the device.

Protocol: this field defines the format of the data sent to the client device. In case BitVoicer Server

is selected, data is wrapped into frames of the BitVoicer Server Protocol (section 6.6 BitVoicer

Server Protocol) before it is sent. In case None is selected, data is simply transformed into a byte

stream and sent without any wrapping.

Input Buffer Size: This field defines the size of the input buffer of the communication interface in

use. BitVoicer Server performs readings from the communication interface every 150 milliseconds.

The input buffer must be capable of storing all bytes received within this interval. In other words, the

size of the input buffer must be defined as a function of the sending rate of the client device.

Output Buffer Size: This field defines the size of the output buffer of the communication interface in

use. The output buffer must be large enough to store the data sent from BitVoicer Server (see Data

Rate described above) given the data rate of the communication interface in use.

4.1.2.3 Nodes

The Nodes tab allows the user to add parts of composite devices or nodes of mesh networks (e.g.

Insteon, Z-Wave, etc.) that are controlled by a single device (usually a USB adapter).

To add a device node, click on an empty grid line, enter the name of the node, its location and save

the device. If a newly created location is not available in the list box, click on the Refresh button located to

the right of the list box.

Nodes can be individually disabled by selecting them on the last grid column (Disabled) and saving

the device. In case a node becomes disabled, it will not receive commands defined in Voice Schemas.

To remove a device node, first select the node by clicking on the line header, then press delete or

right-click on the line and then click on Remove.

The picture below shows the fields in this tab:


http://en.wikipedia.org/wiki/Mesh_networking



4.1.2.4 Cues

The Cues tab allows the user to enable commands (section 4.1.5 Commands) that are executed in

response to input device (Input, Mixed and SystemMic) events. To enable a Cue, select the corresponding

Enable cue checkbox and set the command below it.


Start of Activated Period: This event occurs when the activation word (item 5 of section 3.1.3.2

Validation Filters) is recognized in the audio stream.

End of Activated Period: This event occurs the activation-word-activated period ends (item 6 of

section 3.1.3.2 Validation Filters).




Speech Rejected: This event occurs when the SRE associated with the device rejects a speech

recognition.

Cues can be used to provide visual or sonorous feedback to the user. You can play a .wav file, for

example, to indicate the beginning or ending of the activated period or even send data to input devices when

speech is rejected. The hardware developer can then drive a LED when this data is received.

4.1.3 Binary Data

Binary data objects represent sequences of bytes that can be sent to devices in response to valid

speech recognitions or input device events (section 4.1.2.4 Cues).

In order to send binary data to client devices, you must first create and save the sequence of bytes

and then associate it with one or more commands (section 4.1.5 Commands). There are three ways of

creating binary data objects: through the main menu (File New Binary Data); through the New Binary

Data button ( ) in the toolbar; and through the context menu of the Binary Data category in the Object

Explorer.

The picture below shows the binary data form:

The binary editor is comprised of three columns:

The left column shows the position of the first byte of the line within the byte sequence (array).

The middle column is where you type the bytes in hexadecimal format. Each line has eight fields and

each field represents a byte in the sequence. The editor creates additional fields automatically as

data is inserted. You can use the direction keys to move between fields.

The right column shows the character corresponding to the field value in the ASCII table or a “?”

(question mark) when the character is non-printable.


http://en.wikipedia.org/wiki/ASCII



The binary editor can edit sequences of up to 1023 bytes, which is the maximum length of the

Payload Size field in the BVSP.

You can also import and export binary data through the buttons located above the editor. The

imported/exported file must contain a sequence of bytes (8-bit unsigned integer) serialized by the

BinaryFormatter class.

4.1.4 Voice Schemas

Voice Schemas are the main objects in a BitVoicer Server Solution. They define which sentences

must be recognized, the commands to be executed, which devices are used to capture audio and most of

the Validation Filters (section 3.1.3.2 Validation Filters).

A BitVoicer Server Solution can contain multiple Voice Schemas. Each of them should contain

sentences related to a single functional context (e.g. light control, motor control, temperature control, etc.).

Although a functional context can be applied to different manufacturers, developers or device models, a

Voice Schema should contain commands that are specific to a single device model. This practice facilitates

the sharing and reusing of Voice Schemas.

There are three ways of creating Voice Schema objects: through the main menu (File New

Voice Schema); through the New Voice Schema button ( ) in the toolbar; and through the context menu of

the Voice Schemas category in the Object Explorer.

The following topics describe the tabs within the Voice Schema form and all of its fields.

4.1.4.1 General

The General tab contains Validation Filters and settings for the Voice Schema. The picture below

shows all fields present in this tab and, next to it, a description of each field:


https://msdn.microsoft.com/pt-br/library/system.runtime.serialization.formatters.binary.binaryformatter(v=vs.100).aspx






for naming (e.g. LightControlAEOTECMicroSmartSwitch, SpeechFeedbackArduinoDUE,

ServoControlDAGUSpider, etc.). We also recommend that the Voice Schema name contain at least:

a functional description; the name of the manufacturer or developer; and the hardware model or

software version.

Minimum Confidence Level: It is one of the Validation Filters (section 3.1.3.2 Validation Filters)

used by SREs to determine whether a speech recognition is valid. For a recognition to be valid, the

confidence level at the moment of recognition must be equal to or greater than the value set in this

field. The greater the value in this field, the better must be the pronunciation and the quality of the

audio. In case an input device is associated with different Voice Schemas (section 4.1.4.2 Input

Devices), the smallest confidence level will be used in the Validation Filters.

Activation Word: It is one word, or a set of words, that must be said before the sentence itself. You


activation word and, in the activated period, the sentence itself. The Activation Word can be used to

personalize a Voice Schema or as a strategy to avoid “false positives”. In this last case, we

recommend the use of words with three or more syllables whose occurrence is not frequent in

everyday speech. If an input device is associated with different Voice Schemas, all activation words

in these schemas will start the activation-word-activated period for that device. The use of activation

words is optional.

Activation-word-activated Period: It is the period, in seconds, that starts right after the activation

word is recognized. During this period, the activation word does not have to be repeated for a

recognition to be valid. If an input device is associated with different Voice Schemas, the longest

period will be used in the Validation Filters.

Audio-level-activated Period: It is the period, in milliseconds, that starts when the minimum audio

level (section 4.1.2.1 General) set in the input device is reached. Recognitions performed outside

this period are rejected. If an input device is associated with different Voice Schemas, the longest

period will be used in the Validation Filters.

Latency Period: It is the period, in milliseconds, that starts right after a valid speech recognition.

During this period all recognitions are rejected. If an input device is associated with different Voice

Schemas, the shortest latency period will be used in the Validation Filters.

4.1.4.2 Input Devices

The Input Devices tab allows the user to define which devices will be used as points of capture to the

Voice Schema. When BitVoicer Server detects the presence of an input device, it combines all Voice

Schemas associated with the device, builds its SRE and then assigns the SRE to the device (section 3.1.3.1

Speech Recognition Engine Assignment).

It is import to mention that the lower the number of sentences loaded in a SRE, the better its

accuracy. With that in mind, the user should avoid assigning input devices to Voice Schemas that does not

contain relevant sentences for that location (e.g. a Voice Schema that controls the garage door being

associated with an input device installed in the bathroom).

The picture below shows the Input Devices tab:





The Available list on the left shows the input devices that are not associated with the Voice Schema.

If a recently created device is not visible, right-click on the list and then click on Refresh. The Active list on

the right shows the devices associated with the Voice Schema. To move devices between the lists, use the

direction buttons present between the Available and Active lists.

4.1.4.3 Sentences

The Sentences tab contains the solution objects (sentence blocks and sentence items) that give

origin to Anagrams. Anagrams are all the possible text permutations created from the sentence items. The

picture below shows a sentence with four sentence blocks and multiple sentence items:

The picture above is comprised of the following sentence blocks and sentence items:




Block Block Block Block

Item turn on the lights

Item off tube

Item oven

Item shower

These blocks and items give origin to the following Anagrams. They can be accessed in the

Anagrams/Commands tab:

Anagrams

turn on the lights

turn on the tube

turn on the oven

turn on the shower

turn off the lights

turn off the tube

turn off the oven

turn off the shower

An important aspect of SREs is that they always identify complete Anagrams and not just part of

them. Suppose you have the following Anagram in your Voice Schema: “go forward ten inches.” The SRE

expects to hear the whole sentence and not just part of it as in “go forward.” If you need to have both of

these Anagrams recognized, you have to create two different sentences.

To add or remove sentences, use the buttons available on the top of the tab (Add New Sentence and

Remove Selected Sentences) or right-click on the sentence header and use the options available in the

context menu. To add or remove sentence blocks, use the Add and Remove buttons located after the last

block. Sentence blocks can only be added and removed from the last sentence position.

To add sentence items, simply type them in the grid of each block. You can use the TAB key to

move to the next item and the direction keys to move through them. To remove one sentence item, click on

the item header in order to select it then use the DELETE key or the header context menu.

There is no pre-established limit for the maximum number of sentences a Voice Schema can have.

However, a Voice Schema must have at least one sentence with one sentence block and one sentence item.

4.1.4.4 Anagrams/Commands

The Anagrams/Commands tab shows the Anagrams created from the permutations of the sentence

items (section 4.1.4.3 Sentences). Anagrams are the text sequences that SREs look for in order to execute

the commands associated with them. These commands are created, ordered and edited through the

Anagrams/Commands tab.

The picture below shows the Anagrams created from the example presented in the previous section

and the commands associated with the first Anagram:




In the Anagrams grid, on the left, it is possible to select each Anagram and view, on the right, the

commands associated with them. Anagrams can be associated with multiple commands that are executed in

the order they appear on the screen.

To add a command to an Anagram, select the target Anagram and click on the Add button located in

the Commands area. The command being edited is shown in the Command Properties area (further

information on commands in section 4.1.5 Commands). To remove a command, select it in the Command

grid and click on Remove. It is also possible to change the order of execution of commands by selecting the

target command and clicking on the arrows located to the right of the Command grid.

In some cases, more than one Anagram must be associated with the same set of commands (e.g.

“turn on the yellow led” and “turn the yellow led on” should execute the same command). To avoid creating

these duplicated commands manually, you can copy and paste commands from one Anagram to another. To

do that, select the Anagram from where the commands should be copied and right-click on it. Then, click on

Copy commands and select the Anagram to where the command will be copied. Finally, right-click on the

target Anagram and click on Paste commands. The commands are copied to the destination Anagram in the

same order they appear in the source Anagram.

4.1.5 Commands

Commands define the actions that BitVoicer Server must take in response to valid speech

recognitions or input device events (section 4.1.2.4 Cues). The following sections describe the types of

commands available in BitVoicer Server: RunExecutable, PlayAudio and SendData.

4.1.5.1 RunExecutable

RunExecutable commands enable the user to start applications or open documents. To open

documents through RunExecutable commands, there must be a default editor for the file in the Windows

settings.

The picture below shows the fields present in RunExecutable commands and, next to it, a

description of each field:




Action: Specifies the action to be taken by the command.

File Path: Specifies the complete location of the file to be executed or opened.

Parameters: Defines the parameters to be passed to the executable. Any parameter accepted by

the executable through the command prompt can also be used in this field (e.g. iexplore.exe

google.com).

Delay: Specifies the time interval, in milliseconds, that must be introduced before the command is

executed. This field can be used to control the interval between commands that are executed in

sequence (available only in Voice Schemas).

To be able to use RunExecutable commands, the BitVoicer Server UI Link application must be

running because initializing executables or documents can interact with elements of the user interface.

4.1.5.2 PlayAudio

PlayAudio commands enable the user to send audio streams to client devices or reproduce audio

using the server audio adapter. The reproduced audio can be synthesized speech or a .wav file. If the

content of the .wav file is to be sent to client devices, it must be in the format specified by the BVSP (PCM, 8-

bit, 8000 samples per second, mono – section 6.3.2 Stream Mode). If the .wav file is not in a compatible

format, an error message will be added to the server log (section 4.4 Server Log). The following link is an

online conversion tool capable of generating compatible .wav files: http://audio.online-convert.com/convert-

to-wav. If the .wav file is to be reproduced by the server audio adapter, all formats supported by Windows

can be used.

The picture below shows the fields present in PlayAudio commands and, next to it, a description of

each field:


Audio Source: Specifies the source of the audio to be reproduced or sent to the target device.

Audio sources can be: Synthesizer or WaveFile.

Text: This field is visible only when the audio source is Synthesizer. The text in this field will be

synthesized and reproduced by the server audio adapter or sent to the target device.

File Path: Specifies the complete location of the file to be reproduced or sent to the target device.

This field is visible only when the audio source is WaveFile.


http://audio.online-convert.com/convert-to-wav

http://audio.online-convert.com/convert-to-wav



Target Device: Specifies to where the audio stream must be sent for reproduction. To reproduce

audio using the server audio adapter, select a SystemSpeaker device (section 4.1.2.1 General).

Target Device Node: Specifies which device node (if one is available) is responsible for the audio

reproduction.




Location Specific: When this field is set to true, the command is executed only if the target device,

or its node, is at the same location of the capturing device. A command whose Anagram is “turn

lights on”, for example, should not turn on all lights in a house. Only those lights where the audio was

captured should be turned on.

4.1.5.3 SendData

SendData commands enable the user to send data to client devices in response to valid speech

recognitions or input device events (section 4.1.2.4 Cues). If the target device uses the BVSP, the data is

wrapped into a BVSP frame (section 6.6 BitVoicer Server Protocol) before it is sent.

The picture below shows the fields present in SendData commands and, next to it, a description of

each field:


Data Type: Specifies the type of the data to be sent to the target device. The supported data types

are:

o Byte: 8-bit unsigned integer (0 to 255).

o Int16: 16-bit signed integer (-32.768 a 32.767).

o Int32: 32-bit signed integer (-2.147.483.648 a 2.147.483.647).

o Binary: Sequence (array) of at most 1023 bytes.

o String: Sequence of at most 1023 characters (ISO 8859-1).

Data: Specifies the data to be sent to the target device. This field is only visible if the data type is

Byte, Int16, Int32 or String.

Binary Data: Specifies which of the Binary Data objects contains the data to be sent. This field is

only visible if the data type is Binary.

Target Device: Specifies to where the command data must be sent.

Target Device Node: Specifies which device node (if one is available) is the final destination of the

data.




Location specific: When this field is set to true, the command is executed only if the target device,

or its node, is at the same location of the capturing device. A command whose Anagram is “turn

lights on”, for example, should not turn on all lights in a house. Only those lights where the audio was

captured should be turned on.




4.2 Server Properties

The Server Properties form allows the user to install and select languages, define Validation Filters

and alter the communication settings for client devices and external applications.

There are two ways of accessing the Server Properties form: through the Server Properties button (

) in the toolbar; and through the context menu of the BitVoicer Server item in the Object Explorer.

In order to open the Server Properties form, you must run the BVSM with administrator privileges

(right-click on the manager icon and select “Run as administrator”) or grant administrator privileges when

requested.

The Server Properties form is comprised of three tabs: Speech, Communication and Log. The

following sections describe these tabs and all of their fields.

4.2.1 Speech

The Speech tab allows the user to install and uninstall languages, set the active language and set

the Validation Filters that are applied to all solution objects.

The Override Filters area allows the definition of Validation Filters that have global scope. By

selecting the checkbox of each field, the user can set the value that will override those values present in

devices and Voice Schemas.


Active Language: This list box defines the active language for speech recognition and synthesis. If

the desired language in not listed, it can be installed through the Install/Uninstall Language button to

the right.

Conflict Resolution Period: This Validation Filter is used only when there is more than one input

device at the same location (section 4.1.1 Locations). It consists in waiting a certain amount of time

(milliseconds) after a valid speech recognition and if another recognition occurs at the same location,

only the one with the higher confidence level is considered valid.




Minimum Confidence Level: For a recognition to be valid, the confidence level at the moment of

recognition must be equal to or greater than the value set in this field. The greater the value in this

field, the better must be the pronunciation and the quality of the audio.

Activation Word: It is one word, or a set of words, that must be said before the sentence itself. You


activation word and, in the activated period, the sentence itself.

Activation-word-activated Period: It is the time period, in seconds, that starts right after the

activation word is recognized. During this period, the activation word does not have to be repeated

for a recognition to be valid.

Minimum Audio Level: It is one of the Validation Filters (section 3.1.3.2 Validation Filters) used by

SREs to determine whether a speech recognition is valid. The purpose of this filter is to reject

speech sources with low intensity and the general rule to set its value is: the more sensitive the

capture device, the higher must be the minimum audio level. The Server Monitor tool provides real-

time information about the audio levels of input devices and can be used to determine the value of

this field.

Audio-level-activated Period: It is the time period, in milliseconds, that starts when the minimum

audio level is reached. Recognitions performed outside this period are rejected.

Latency Period: It is the time period, in milliseconds, that starts right after a valid speech

recognition. During this period all recognitions are rejected.

The Install/Uninstall Language button gives access to the Language Installation tool:

To install a new language, select it in the Uninstalled Languages list and click on Install Selected

Language. To uninstall a language, select it in the Installed Languages list and click on Uninstall Selected

Language.

Additional languages are not part of the BitVoicer Server installation package. They are downloaded

from the BitSophia’s servers on the Internet. For that reason, if you experience installation issues, make sure




that the Windows and network firewalls are not blocking the BVSM and disable all connection proxies (Start

Control Panel Network and Internet Internet Options Connections tab LAN settings).

4.2.2 Communication

The Communication tab allows the user to set up TCP and WCF ports, control the execution of the

BitVoicer Server UI Link application and define inactivity timeouts.


Listener TCP Port: This TCP port is used by BitVoicer Server to create a TCP/IP listener that

accepts incoming connections from client devices. If another application on the server uses the

same TCP port set in this field, you must change the port in the conflicting application.

WCF HTTP Port: This port is used by external applications to access the WCF services available in

BitVoicer Server (sections 3.1.3.5 Speech Manager and 3.1.5 Data Forwarding).

Data Forwarding Buffer: The Data Forwarding Module stores frames sent from client devices so

that they can be retrieved by external applications. This field defines the maximum quantity of frames

stored by the Data Forwarding Module for each device. If the number of frames reaches the value

defined in this field and a new frame is received, the oldest frame is discarded (FIFO buffer) to

provide space for the new frame.

Data Forwarding Idle Timeout: If an external application gets connected to the Data Forwarding

Module, but keeps itself inactive for the period, in minutes, defined in this field, all resources used by

the application are discarded and the WCF connection is closed. In this case, the external

application will have to create a new WCF connection to regain access to the service.

Speech Interface Idle Timeout: If an external application gets connected to the Speech Manager

Module, but keeps itself inactive for the period, in minutes, defined in this field, all resources used by

the application are discarded and the WCF connection is closed. In this case, the external

application will have to create a new WCF connection to regain access to the service.

Disable User Interface Link: Some Commands executed by BitVoicer Server require interaction

with the user interface. This interaction is performed by the BitVoicer Server UI Link application. If

this checkbox is selected, BitVoicer Server disables the communication with this application and


http://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)



stops its execution. Once this checkbox is selected, the BitVoicer Server UI Link application will no

longer load after the Windows initialization.

4.2.3 Log

This tab contains a single field: Maximum Log Size. This field defines the maximum number of

operational events BitVoicer Server must store (further information about the BitVoicer Server logs in section

4.4 Server Log). When the log reaches its maximum capacity, the oldest entries are discarded to provide

space for the new entries.

4.3 Manager Options

The manager options define the operating mode of some of the BVSM features.

To access the Options form click on Tools Options in the main menu. The picture below shows all

fields present in this form and, next to it, a description of each field:

Auto-refresh Anagrams: When the user is editing Voice Schemas, the generation of Anagrams is

performed from the sentences defined in the Sentences tab. For this reason, every time the

Anagrams/Commands tab is selected, the Anagrams are automatically recomputed. This process

may cause some delays if the Voice Schema has a great number of sentences. To prevent the

manager from recomputing all Anagrams every time the Anagrams/Commands tab is selected,

uncheck this checkbox. When this option is unchecked, the user must refresh the Anagrams grid

manually through its context menu.

Disable the ‘take effect’ Warning in the Server Properties Form: When the Server Properties

are saved, the server must be restarted for the changes to take effect. The BVSM warns the user




about this requirement every time the properties are saved. To disable this warning, you must check

this option.

Confirm Solution Object Exclusions: When this option is checked, the BVSM always prompts the

user for confirmation before excluding solution objects.

Confirm Log Exclusions: when this option is checked, the BVSM always prompts the user for

confirmation before excluding log entries.

Confirm Sentence Exclusions: When this option is checked, the BVSM always prompts the user

for confirmation before excluding sentences from Voice Schemas.

Confirm Sentence Block Exclusion: When this option is checked, the BVSM always prompts the

user for confirmation before excluding sentence blocks from Voice Schemas.

The Commands tab (picture below) allows the user to set the default command for Devices and

Voice Schemas. When the user adds Cues to devices or commands (section 4.1.4.4 Anagrams/Commands)

to Voice Schemas, the command defined in this tab will be added to the command editor of the object being

edited.

4.4 Server Log

BitVoicer Server maintains two types of logs: operational log and error log. The operational log

contains regular event entries that occur during the server operation: solution object changes, data sending,

command execution, data forwarding, speech recognition, and speech synthesis. The error log contains

error or exception entries that compromise the correct server operation.

The operational log is stored in a file managed directly by BitVoicer Server and can be viewed

through the Server Log tool. This tool can be accessed through the main menu (View Server Log) or

through the Server Log button ( ) available in the toolbar. The picture below shows the log viewer tool:




In the Filter area, the user can select which entries will be shown in the event grid. It is possible to

filter the entries by server module (section 3.1 Server Modules) or show all entries. After selecting the

desired module, you must click on the Apply button for the entries to be filtered.

The event grid does not automatically update its content. To view the most recent entries generated

by the server, you must click on the Refresh button located to the right of the filter area.

The Clear button excludes all entries stored in the log file and cleans the event grid.

The event grid is comprised of four adjustable columns: the first column shows, in descendent order,

the date and time the event occurred; the second column shows the module responsible for the event; the

third column shows the user that generated the event; and the forth column shows a description of the event.

Events generated by the server (events that do not require user interaction) or by client devices are assigned

to the user account in which the BitVoicer Server service is running.

The error log is stored by Windows along with the operating system and application logs. To view

this log, click on Start in the taskbar, type “Event Viewer” and press ENTER. In the Event Viewer, browse to

Windows Log Application. In the central area of this screen you can see the log entries of all applications

installed on the server. In the Source column, look for entries with the description “BitVoicer Server” or filter

the results using the tools available to the right of the entry list.

4.5 Server Monitor

The Server Monitor tool allows the user to view: the status of the server modules; which devices are

connected; what are the last speech recognition results; and the status, in real-time, of the speech

recognition engines. It also allows the user to perform communication tests using the Data Forwarding

Module.




The Server Monitor tool can be accessed through the main menu (View Server Monitor) or

through the Server Monitor button ( ) available in the toolbar. The following sections describe each of the

tabs available in this tool.

4.5.1 General

The General tab, picture below, shows general information about the Communication Manager, Data

Forwarding e Speech Manager Modules:

The Communication area reports if the Communication Manager Module is operational and the

number of connected devices. If the status of this module is Stopped, no device will be able to connect to the

server and the other modules, even if they are operational, will not be able to establish communication with

client devices.

The Data Forwarding area reports if the Data Forwarding Module is operational and the number of

active bindings between client devices and external applications. Binding is the method through which

external applications establish communication with client devices (section 7.1.3.3 DataForwardingClient). At

any moment, multiple external applications can be bound to multiple client devices simultaneously.

The Speech area reports if the speech recognition and synthesis features are operational, and the

number of available and assigned speech recognition engines. If there are no licenses installed on the

server, the speech recognition will not be enabled and the Recognition status item will show stopped. The

Assigned Engines item shows how many speech recognition engines are assigned to input devices. Engines

are assigned (section 3.1.3.1 Speech Recognition Engine Assignment) to input devices even if these devices

are not associated with any Voice Schema (section 4.1.4.2 Input Devices).

If the status of any of the modules in this tab is stopped because of a server error, further information

about the error will be made available in the Windows log (section 4.4 Server Log).

4.5.2 Communication

The Communication tab shows the devices that were identified by the Communication Manager and

are currently connected to the server.




4.5.3 Data Forwarding

The Data Forwarding tab allows the user to perform communication tests with client devices using

the Data Forwarding Module. The picture below shows the Data Forwarding tab and the result of the test

described in section 8.4 Using the Data Forwarding Module:

The Device area shows a list box with all devices present in the solution, except for SystemMic and

SystemSpeaker devices. After a device is selected, you can bind (using the Bind button) to it and perform




data exchange. This tool supports binding to one device at a time. However, the Data Forwarding Module

supports simultaneous binding of multiple devices to multiple applications.

When the Server Monitor is successfully bound to a device, you can send data through the Send

area and receive data through the Receive area. To send data, select the data type in the Data Type list box,

type the data in the textbox right below it and click on the Send button. At this moment, a BVSP frame

(section 6.6 BitVoicer Server Protocol) containing the specified data is sent to the client device. The

Received area is automatically updated and shows the data sent from the bound device.

To bind to a different device, you must first unbind from the current device using the Unbind button.

4.5.4 Speech

The Speech tab shows information about the last recognition results (accepted and rejected) and the

real-time status of the speech recognition engines.

The Recognition Results area, picture below, shows details about the last ten speech recognitions.

In this area the user can view: which device captured the audio; if it was accepted or rejected; the rejection

reason; the recognized text; the moment of recognition; the confidence level; and the audio levels at the

moment of recognition.

The Engine Status area shows real-time information about speech recognition engines. This

information is also used by the Validation Filters to determine whether a recognition is valid. To view the

status of a specific engine, select an input device in the Recognition client list box. This list box only shows

the input devices that were active when the Server Monitor tool was first opened. If a device became active

after the tool was opened, click on the Refresh button so that the new device also becomes listed.

The Audio Level field shows the most recent volume (0 to 100) measured in the audio stream. The

Audio Level Average field shows the average of the last measurements. The In Audio-level-activated Period




and In Activation-word-activated Period fields show true when the speech recognition engine is within these

periods (section 3.1.3.2 Validation Filters).

4.6 Exporting Solution Objects

The BVSM Export Wizard (Main Menu Tools Export Solution Objects) enables the user to

quickly duplicate BitVoicer Server installations, create backups and share solution objects. It generates .sof

(Solution Object File) files that can imported through the Import Wizard (section 4.7 Importing Solution

Objects).

The picture below shows the first step of the Export Wizard:

The first step of the wizard consists in specifying the content of the solution object file:

Voice Schemas and Commands: This option exports the selected Voice Schemas, their sentences

and Anagrams, the commands related to these Anagrams and all binary data related to these

commands.

Voice Schemas Only: This option exports the selected Voice Schemas, their sentences and

Anagrams. Related commands and binary data are ignored.

Devices: this option exports the selected devices and their cues (section 4.1.2.4 Cues), including

the devices and binary data related to these cues.

Binary Data: This option exports only the selected binary data.

The second step (pictured below) consists in specifying the full path to the file to where the solution

objects will be exported. You can browse through the server folders using the Browse button.




The third and last step (pictured below) consists in selecting which objects will be exported:

After the objects have been selected, click on Finish for the Export Wizard to gather the necessary

information and export the selected objects to the specified file. The picture below shows the result of this

process:




If an error occurs during the exporting process, the Message column will show a link where the error

description can be found.

4.7 Importing Solution Objects

The Import Wizard enables the user to import solution objects that were exported to .sof (Solution

Object File) files through the Export Wizard.

The Import Wizard can be accessed through the main menu (Tools Import Solution Objects). The

picture below shows the first step of the Import Wizard:




The first step of the wizard consists in specifying the file from where the solution objects will be

imported. In the next steps, the Import Wizard will request information based on the content of this file. The

following sections describe the wizard steps for the four types of content: Voice Schemas and commands;

Voice Schemas only; devices; and binary data.

4.7.1 Importing Voice Schemas and Commands

When the import content is Voice Schemas and commands, the form below is shown in the second

step of the Import Wizard:

If the Select input devices option is checked, the step shown in the next picture will be added to the

Import Wizard. In this step, you can specify which devices will be used as Input Devices to the selected

Voice Schemas.

If the Merge identical binary data option is checked, all binary data whose name and content is

identical to existing binary data are not imported. Commands that use these objects are mapped to existing

binary data. Binary data that have no equivalent in the solution are imported normally.




In the third step of the Import Wizard (pictured below) the user must select the Voice Schema objects

to be imported:

In the last step of the Import Wizard, the user must map the target devices of the commands being

imported. The first three columns of this step (picture below) show information about the original target

devices. Using the last two columns, the user must map each original target device to a device already

present in the solution.




After the devices are mapped, click on Finish for the Import Wizard to gather the necessary

information and import the selected objects to the solution. The picture below shows the result of this

process:

If an error occurs during the importing process, the Message column will show a link where the error


4.7.2 Importing Voice Schemas Only

When the import content is Voice Schemas only, without commands and binary data, the form below

is shown in the second step of the Import Wizard:




If the Select input devices option is checked, the step shown in the next picture will be added to the

wizard. In this step, you can specify which devices will be used as Input Devices to the selected Voice

Schemas.

In the third step of the Import Wizard (pictured below) the user must select the Voice Schema objects

to be imported:




If the Select Input Devices option was not checked, this is the last step of the wizard. If that is the

case, click on Finish for the Import Wizard to gather the necessary information and import the selected

objects to the solution. The picture below shows the result of this process:



4.7.3 Importing Devices

When the import content is Devices, the form below is shown in the second step of the Import

Wizard:




If the Merge identical binary data option is checked, all binary data whose name and content is

identical to existing binary data are not imported. Commands that use these objects are mapped to existing

binary data. Binary data that have no equivalent in the solution are imported normally.

The Map Locations and Merge Locations options are mutually exclusive (only one of them can be

selected). If Map Locations is selected, the step shown in the next picture will be added to the Import Wizard.

In this step, the user must map the original imported device locations to locations already present in the

solution.

If the Merge Locations option is selected, the Import Wizard will create the locations that do not exist

in the solution and map the matching locations to existing locations.

In the third step of the Import Wizard (pictured below) the user must select the device objects to be

imported:




In the fourth step of the Import Wizard (pictured below) the user can alter the communication settings

of the imported devices. If the device uses a SerialCOM (serial port) communication interface, the user can

alter its port name. If the device uses a TCPIP communication interface, the user can alter the IP address of

the device.

If any of the imported devices have Cues (section 4.1.2.4 Cues) and the target device of a Cue is not

imported, the user will have to map the target of this Cue to an existing device. In this case, the step below

will be added to the Import Wizard:




The first three columns of this step (pictured above) show information about the original target

devices of the Cues being imported. Using the last two columns, the user must map each original target

device to a device already present in the solution.

After the devices are mapped, click on Finish for the Import Wizard to gather the necessary


process:






4.7.4 Importing Binary Data

When the import content is Binary data, the form below is shown in the second step of the Import

Wizard:

If the Skip identical binary data option is checked, all binary data whose name and content is

identical to existing binary data are not imported.

In the next step (pictured below) the user must select the Binary Data Objects to be imported:

After the objects are selected, click on Finish for the Import Wizard to gather the necessary


process:






4.8 Speech Recognition and Synthesis Trials

The BVSM has two tools where the user can try the speech recognition and synthesis without the

need to acquire licenses. These tools use only the server audio adapter and do not require connections with

client devices.

Before you use these tools, make sure the audio adapter is correctly installed (Start Control Panel

System and Security Device Manager), and the microphone and speaker levels are not at the minimum

level (Start Control Panel Hardware and Sound Sound).

To access the speech recognition trial tool (pictured below) click on Tools Try Speech Recognition

in the main menu:




To access the speech synthesis trial tool (pictured below) click on Tools Try Speech Synthesis in

the main menu:




4.9 Activation

The BitVoicer Server licenses are activated through the Activation Tool located in the main menu

(Help Activation). To access this tool, the server must be connected to the Internet and the user must run

the BVSM with administrator privileges or grant administrator privileges when requested.

The Activation Tool (pictured below) is comprised of a grid for entering product keys, a Status area

and an Activation Report area.

The BitVoicer Server product keys are comprised of five blocks and each block is comprised of four

alphanumeric characters. To activate one or more product keys, type them in the grid and click on Activate.

The Activation Report area will show detailed information about the activation process. Once the activation

process is finished, you must restart BitVoicer Server.




5 BitVoicer Server UI Link

The BitVoicer Server UI Link (UI Link) application enables BitVoicer Server to execute Commands

and access resources that require interaction with the user interface. When the server audio adapter is used

to capture or reproduce audio, for example, BitVoicer Server is interacting with the user interface. In addition

to that, commands that start applications or open documents may also require such interaction.

The UI Link application is loaded when the operating system is initialized. However, it stays hidden in

the Windows task bar most of the time. Only when error messages are shown, a small icon appears next to

the clock area.

To access the UI Link application, click on the small arrow-shaped icon (system tray) next to the

clock area as shown in the picture below:

The UI Link icon can take two forms in the system tray:

The icon with the red square (stopped) indicates there is a communication problem with BitVoicer

Server and the UI Link is not executing commands. The icon with the green triangle (running) indicates the

UI Link is working properly.

You can control the execution of the UI Link (pictured below) through its main menu or through the

context menu (right mouse button) available in the application icon.




The File item in the main menu enables the user to control which operations the UI Link is authorized

to execute:

Do not listen: The UI Link will not use the microphone of the server to capture audio.

Do not speak: The UI Link will not use the speakers of the server to reproduce synthesized speech.

Do not play audio: The UI Link will not use the speakers of the server reproduce .wav files.

Do not start processes: The UI Link will not run executables nor open documents.

The Recent Activity area shows the last commands executed by the UI Link. The Messages area

shows the description of communication or execution errors if they occur.

To keep the UI Link running, do not close the application through the “X” button. Use the minimize

button instead.

In case you want to disable the UI Link completely, check the Disable user interface link option in the

server properties (section 4.2.2 Communication).




6 BitVoicer Server Protocol

The BitVoicer Server Protocol (BVSP) is used by microcontrollers to access the data forwarding,

speech recognition and synthesis services of BitVoicer Server.

6.1 Definitions

Application: Group of one or more programs designed to perform operations with a specific

purpose.

Audio Stream: Digital representation of sound waves comprised of a sequence of bits.

Capture Point: Physical location where sound waves are converted into electrical impulses.

Client Device: Device that uses the services available on the server.

Communication Direction: Direction in which data is transmitted (inbound or outbound).

Communication Endpoint: Point where data leave an entity and pass to a communication

interface, and vice-versa.

Communication Interface/Channel: The medium and protocol through which information units

(bits) are transmitted from a communication endpoint to another in any direction.

Device: Group of hardware and possibly software, comprised of one or more integrated circuits or

MCUs, accompanied by other components or not, capable of accessing the services of the server

through a communication interface.

Inactivity Timeout: Maximum amount of time, in seconds, that a TCP/IP connection can remain

inactive (no data exchange) before all resources associated with it are discarded and the connection

is closed.

Inbound: Direction of the communication when data is sent from a device to the server.

Input Device: Device that captures and sends audio to the server.

Inter-process Communication: Group of mechanisms that enable processes to exchange

information.

Little-endian: The least significant byte or bit first (LSB).

MCU (Microcontroller Unit): Microcontroller comprised of processor, memory and input/output

peripheral.

Mixed Device: Device capable of acting as input and output device.

Mode Changing Signal: Signal that requests an operating mode change of a communication

channel in a particular direction.

Outbound: Direction of the communication when data is sent from the server to a device.

Output Device: Device that receives data from the server in response to valid speech recognitions.

Payload: The data to be transmitted, excluding the information sent with it (e.g. headers or

metadata).

PCM (Pulse-Code Modulation): Method to digitally represent samples of analogic signals.

Process: Execution context that abstracts the code execution from the real system components.

Processes are usually not aware of other processes.

Program: Sequence of instructions designed to perform specific tasks in a data processing unit.

Server: Data processing unit that uses this protocol to provide speech recognition and synthesis

services.

Socket: Implementation of the Berkeley socket interface.

TCP/IP Listener: A TCP/IP connection-oriented socket that monitors connection attempts.

Typified Data: Data whose content is determined.

Valid Speech Recognition: Occurs when the server analyzes an audio stream and identifies one or

more pre-defined words under pre-defined conditions.




6.2 Scope

This protocol defines the form of communication between the BitVoicer Server communication

endpoints and client devices. The inter-process communication performed between BitVoicer Server and

other applications running on the server is not part of the scope of this protocol.

The BVSP does not impose restrictions regarding the intermediary communication interfaces used to

connect two communication endpoints.

6.3 Basic Concepts

The BVSP provides two distinct operating modes: Framed and Stream. These operating modes can

be independently altered, at any moment, in any communication direction. In other words, the operating

mode can be different in each direction (inbound and outbound).

6.3.1 Framed Mode

In this operating mode all exchanged information is wrapped into frames. The frames are comprised

of delimiter and qualifier fields in addition to the payload. Framed is the initial operating mode, in both

directions, when a connection is established with the server. Status information and typified data can only be

exchanged in this mode.

6.3.2 Stream Mode

In this operating mode all exchanged information is sent as binary streams comprised of octets (8-bit

blocks). The content of the data is 8-bit PCM audio at 8000 samples per second. When the communication is

performed in this mode, all data received by the communication endpoint must be treated as audio. To

resume to Framed mode, the mode changing signal must be inserted into the audio signal and sent to the

other communication endpoint.

Only input and mixed devices can alter the inbound channel (Device Server) to Stream mode. In

other words, only input and mixed devices can act as capture point and send audio streams to the server.

6.3.3 Speech Recognition Engine

Speech Recognition Engine (SRE) is a process executed on the server for each client device

operating an inbound channel in Stream mode. This process receives and manages audio streams, identifies

one or more words in this stream, validates the identifications through predefined conditions and sends data

to one or more client devices in response to valid identifications.

The words to be identified or recognized are predefined on the server and can be associated with

one or more client devices. The validating conditions, in turn, can be defined individually to each device or to

all devices that use a determined set of words.

The data sent in response to valid speech recognitions, its type and target are also predefined on the

server. Valid recognitions can lead to the sending of data to the device that captured the audio or to other

client devices.

6.4 Communication Interfaces

The BVSP supports two types of communication endpoints: TCP/IP and serial port. These

communication interfaces are operated differently by the server as described in the following subsections.

6.4.1 TCP/IP

When using this communication interface, the server implements a TCP/IP listener that waits for

socket-based connection requests. The default TCP port used by the listener is port 4194.




The identification of the device that requests a connection to the listener is performed through the IP

address of the device’s communication interface. The server uses a list of devices to accept incoming

connections. This list contains the IP addresses that identify each client device in the network. If the IP

address of the device that requests a connection is present in the list of devices, the TCP/IP connection is

accepted and immediately opened. If the IP address of the device that requests a connection is not present

in the list of devices, the connection is immediately refused and no data is sent to the requesting device.

Once a connection is accepted, the server sends one frame containing status information and the

device can start exchanging data with the server. Since this status frame is not generated upon a client

request, the random number, which is mandatory in this type of frame, will be zero.

In case there is no data exchange on a TCP/IP interface for a period longer than the inactivity

timeout, the TCP/IP connection is closed by the server and all resources associated with it are released.

6.4.2 Serial Port

When using this communication interface, two connection modes are available: Intermittent and

Persistent. The connection mode used by each device is established in the list of devices stored on the

server. This list contains all serial ports to be monitored, their specifications and connection mode.

6.4.2.1 Intermittent Connections

Intermittent Serial Connections are those in which the server does not permanently block access to

the serial port. In this type of connection, the server only blocks the port during the brief period of time that it

needs to send data to devices or MCUs. If the serial port is not available for connection at the moment the

server needs to send data to it, two other connection attempts are made in 500 millisecond intervals. If none

of the attempts are successful, the server discards the data.

This type of connection can only be used by output devices because input devices must be

connected to the server at all times in order to send audio streams.

6.4.2.2 Persistent Connections

Persistent Serial Connections are those in which the server permanently blocks access to the serial

port, that is, the connection to the serial port is persistent.

A list of devices that use this connection mode indicates which serial ports must be monitored by the

server. Every 300 milliseconds the server verifies the serial ports available on the equipment that runs the

server and opens those ports present in the list of devices. At the same moment, if a serial port that was

already opened becomes unavailable, it is immediately closed and all resources associated with it are

released.

Once a serial port is opened, the server sends one frame containing status information and the

device can start exchanging data with the server. Since this status frame is not generated upon a client

request, the random number, which is mandatory in this type of frame, will be zero.

6.5 Operational Description

This section describes how to operationalize the information exchange between devices and the

server.

6.5.1 Initial Operating Mode

The initial operating mode of the BVSP, in both communication directions, is Framed. The protocol is

considered to be initialized when client devices can start exchanging data with the server. This moment

varies according to the communication interface used by the device (further details in section 6.4

Communication Interfaces).




6.5.2 Changing the Operating Mode

Once the protocol is initialized, the participants of the communication can control the operating mode

of their outgoing communication. In other words, client devices are responsible for controlling the operating

mode in the inbound direction (Device Server) and the server is responsible for controlling the operating

mode in the outbound direction (Server Device).

6.5.2.1 Changing the Operating Mode to Stream

To request the changing of the operating mode to Stream, the communication endpoint that controls

the channel must send a Mode Change frame. The communication endpoint that receives the frame must

take the appropriate actions to start processing the received data as audio stream.

6.5.2.2 Changing the Operating Mode to Framed

When data exchange between communication endpoints, in a particular direction, is operating in

Stream mode, the communication endpoint that receives the data processes it as PCM audio stream. To

instruct the communication endpoint that receives the data that the operating mode of the channel must

change to Framed, a mode changing signal must be inserted into the audio stream and detected by the other

communication endpoint. This signal is comprised of the following bytes (octets): 0xFF, 0xFF, 0xFF, 0xFF,

0x00, 0x00, 0x00, 0x00, 0xFF.

The communication endpoint that receives the mode changing signal must, immediately, abandon

the Stream mode. Therefore, the next byte received after the end of the mode changing signal is the byte

that identifies the beginning of a frame.

6.5.3 Requesting Server Status

Server status requests can only be sent when the inbound communication channel (Device

Server) is operating in Framed mode. If the inbound channel is operating in Stream mode, the client device

must change the operating mode of the inbound channel to Framed before sending status requests.

To request status information to the server, one Status Request frame must be sent to the server.

Once this frame is received and processed, the server creates another frame containing status information

and immediately sends it back to the requesting device. The information contained in this frame is described

in details in section 6.6.1.5.1 Status Payload.

The time interval to receive, process and respond to Status Request frames is mostly influenced by

the time it takes for the communication interface to send and receive the frames. For that reason, it is

possible to use this mechanism to identify if the server is still in reach or the communication channel is no

longer operating.

6.5.4 Speech Recognition

When the server identifies the presence of an input or mixed device and a connection is established,

an exclusive SRE is assigned to the device. From this moment, if the server receives a request to change

the inbound channel operating mode (Device Server) to Stream, all data received in this channel will be

forwarded to the SRE responsible for processing the audio. The SRE is described in details in section 6.3.3

Speech Recognition Engine.

When the server disconnects from an input or mixed device, it immediately releases the SRE

assigned to the device.

6.5.5 Forwarding Data to Applications on the Server

In order to forward data to applications running on the server, the inbound communication channel

(Device Server) must be operating in Framed mode. If this channel is operating in Stream mode, the client

device must change the operating mode of the inbound channel to Framed before sending data.




To forward data to other applications, the client device must send Data Transfer frames to the

server. The server, in turn, forwards the data in these frames to a temporary storage capable of handling

inter-process communication. Other processes (applications) can then perform queries to this storage and

retrieve the data sent from client devices.

The inter-process communication performed between the server and other applications is not part of

the scope of this protocol and must be specified in the documentation of the server that implements this

protocol.

6.5.6 Receiving Typified Data from the Server

In order to receive typified data from the server, the outbound communication channel (Device

Server) must be operating in Framed mode. If this channel is operating in Stream mode, the server must

change the operating mode of the outbound channel to Framed before sending data.

Data sent from the server is wrapped into Data Transfer frames. This data can come from other

applications (inter-process communication) or it can be the result of a valid speech recognition. The client

device that receives the data must be able to handle both data sources without distinction because the

server does not inform which data source sent the data.

6.6 BitVoicer Server Protocol Frame Structure

The basic unit of transmission in Framed mode is the frame. The table below shows the fields that

compose the frame.

Byte Bit Field

0 7 to 0 START OF FRAME

1

1 TYPE OF FRAME

0

3

TYPE OF DATA 2

1

0

9

PAYLOAD SIZE

8

2

7

6

5

4

3

2

1

0

3 to N --- PAYLOAD

N + 1 7 to 0 END OF FRAME

N = 2 + Payload Size

Bytes sent from

the top to the

bottom




6.6.1 Fields of the Frame

The BVSP frames are comprised of fields. These fields are described in the next sections in the

order they are transmitted. The ordering of bytes and bits used in the protocol is Little-endian.

6.6.1.1 Start of Frame

This field marks the beginning of a BVSP frame and consists of the sequence 10101011 (0xAB).

6.6.1.2 Type of Frame

This field is comprised of two bits that identify the type or function of the frame. The types of frames

are:

Data Transfer: The field value is 0x00.

Status Request: The field value is 0x01. The data type of the Status Request frame must be Byte,

the Payload Size must be one and the Payload field must contain a random number between 0 and

255. The returned frame must contain data of type Status.

Mode Change: The field value is 0x02. The data type of the Mode Change frame must be N/A, the

Payload Size must be zero and the Payload field must be excluded from the frame.

6.6.1.3 Type of Data

This field is comprised of four bits and it indicates the type of data contained in the Payload field. The

types of data supported by the protocol are:

Type Value Description

N/A 0x00 Indicates that data classification does not apply to the frame.

Byte 0x01 8-bit unsigned integer. Interval: 0 a 255.

Int16 0x03 16-bit signed integer. Interval: -32.768 a 32.767.

Int32 0x05 32-bit signed integer. Interval: -2.147.483.648 a 2.147.483.647.

Binary 0x07 Byte array of variable length. Maximum length: 1023 bytes.

String 0x08 Character string (ISO 8859-1) of variable length. Maximum length: 1023 bytes.

Status 0x0F

This data type indicates the server status. The Payload field of frames containing this data type is comprised of two bytes: the first byte contains the random number sent by the client device that requested the status; the second byte contains the status information itself (section 6.6.1.5.1 Status Payload).

6.6.1.4 Payload Size

This field is comprised of ten bits and it indicates the number of bytes contained in the Payload field.

The maximum value of this field is 1023.

6.6.1.5 Payload

This field contains the data to be transmitted. The data type is determined by the Type of Data field

and the number of bytes is determined by the Payload Size field.

If the frame data type is Status (0x0F), the Payload field will contain two bytes. The next section

describes in details the attribution of each of these bytes.




6.6.1.5.1 Status Payload

Status payloads consists of two bytes:

First Byte: Contains the random number generated and sent from the client device that requested

the status frame.

Second Byte: The bits in this byte indicate different server status information. Bits equal to zero

indicate false and bits equal to one indicate true.

Bit Description

7 a 3 (Reserved)

2 Data forwarding active: Indicates if the data forwarding service is running.

1 SRE available: Indicates if there is one SRE assigned to the device.

0 Running: Indicates whether the server is up and running.

6.6.1.6 End of Frame

This field marks the end of a BVSP frame and consists of the sequence 01010111 (0x57).

6.7 Notes

The BVSP does not define features to identify and recover from transmission errors nor to

acknowledge received frames. These features must be implemented by inferior layers. All inconsistent

frames are simply discarded.

Sources of inconsistency include:

Missing or unidentified fields;

Incorrect frame sizes (considering the value in the Payload Size field);

Unsupported field values.

6.8 Open Specifications

This protocol is intellectual property of BitSophia Tecnologia Ltda - ME. BitSophia irrevocably

promises not to assert any claims against you for using, selling, exporting, importing or distributing devices

that implement the specifications of this protocol as long as:

a. All protocol specifications are strictly implemented;

b. No part of the specifications is modified, adapted or extended;

c. The device in which the protocol is implemented uses the services of a licensed copy of BitVoicer

Server;

d. The BitVoicer and BitSophia trademarks are not used in any advertising or publicity material,

documentation, product or service without explicit authorization.

This is a personal promise directly from BitSophia to you, and you acknowledge as a condition of

benefiting from it that no BitSophia rights are received from suppliers, distributors, or otherwise in connection

with this promise.




7 Library References

This section contains the documentation of the libraries available in the BitVoicer Server installation

package. The C# Library wraps the Windows Communication Foundation (WCF) services exposed by

BitVoicer Server and provides functionalities that facilitate the integration of the server with other .Net

applications. The Arduino Libraries implement all services available on BitVoicer Server and once they are

written in C/C++, they can be easily ported to other hardware platforms.

7.1 C# Library

This library is located in the BitVoicer Server installation folder (usually C:\Program

Files\BitSophia\BitVoicer Server).

Assembly: bvsi.dll

7.1.1 BitSophia.BitVoicerServer.Integration

The BitSophia.BitVoicerServer.Integration namespace contains types that allow the integration of the

Speech Manager and Data Forwarding Modules with other .Net applications. The SpeechMonitor and

DataForwardingMonitor classes are the main classes in this namespace. They wrap the WCF services of the

above modules and provide additional functionalities that simplify the integration with these modules.

7.1.1.1 DataForwardingMonitor Class

DESCRIPTION:

Wraps and extends the WCF services of the Data Forwarding Module.

SINTAX:

public class DataForwardingMonitor : IDisposable

CONSTRUCTORS:

public DataForwardingMonitor(): Initializes a new instance of the DataForwardingMonitor class using

default settings.

public DataForwardingMonitor(double refreshInterval): Initializes a new instance of the

DataForwardingMonitor class using the specified refresh interval.

Parameters:

double refreshInterval: The interval, in milliseconds, at which the DataForwardingMonitor

verifies if there are available frames on the server. The minimum value for this parameter is 100

milliseconds.





public DataForwardingMonitor(int port): Initializes a new instance of the DataForwardingMonitor class

using the specified port.

Parameters:

int port: The port in which the DataForwarding WCF service is listening.

public DataForwardingMonitor(double refreshInterval, int port): Initializes a new instance of the

DataForwardingMonitor class using the specified refresh interval and port.

Parameters:

double refreshInterval: The interval, in milliseconds, at which the DataForwardingMonitor

verifies if there are available frames on the server. The minimum value for this parameter is 100

milliseconds.

int port: The port in which the DataForwarding WCF service is listening.

PROPERTIES

public bool IsRunning: Gets a value that indicates whether the DataForwardingMonitor is checking if

there are available frames on the server.

public bool IsConnected: Gets a value that indicates whether the DataForwardingMonitor is connected

to the DataForwarding service.

public bool IsDisposed: Gets a value that indicates whether the DataForwardingMonitor has been

disposed of.

public ISynchronizeInvoke SynchronizingObject: Gets or sets the object used to marshal event-

handler calls that are issued when the Faulted and DataReceived events occur.




Remarks:

By default, the methods that handle the Faulted and DataReceived events are called on a thread

from the system-thread pool. When the Faulted and DataReceived events are handled by a visual

Windows Forms component, such as a form, accessing the component through the system-thread

pool might result in an exception or just might not work. Avoid this effect by setting

SynchronizingObject to a Windows Forms component, which causes the methods that handle the

Faulted and DataReceived events to be called on the same thread that the component was created

on.

METHODS:

public bool Bind(byte[] serialNumber): Associates the current instance of the DataForwardingMonitor

with a client device.

Parameters:

byte[] serialNumber: A byte array containing the serial number of the device to which to bind.

Return value:

bool: True if the binding is successful. Otherwise, false.

public void Connect(): Connects the DataForwardingMonitor to the DataForwarding WCF service.

public int CountAvailableFrames(): Returns the number of available frames sent from devices to which

the DataForwardingMonitor is bound.

Return value:

int: The number of available frames. If no frame is available or the DataForwardingMonitor is not

bound to any device, it returns zero.

public int CountActiveBindings(): Returns the number of devices to which the DataForwardingMonitor

is bound.

Return value:

int: The number of devices to which the DataForwardingMonitor is bound. If the

DataForwardingMonitor is not bound to any device, it returns zero.




public void Disconnect(): Disconnects the DataForwardingMonitor from the DataForwarding WCF

service.

public void Dispose(): Releases all resources used by the current instance of the

DataForwardingMonitor class. Always call this method before you release the last reference to this

class.

protected virtual void Dispose(bool disposing): Releases the unmanaged resources used by the

DataForwardingMonitor, and optionally disposes of the managed resources.

Parameters:

bool disposing: True to release both managed and unmanaged resources; false to releases only

unmanaged resources.

public Device[] GetSolutionDevices(): Returns a Device array containing all devices present in the

solution.

Return value:

Device[]: An array of type BitSophia.BitVoicerServer.Integration.DataFwdService.Device

containing all devices present in the solution or an empty array if no device is found.

public ForwardedData Receive(): Receives one frame from the DataForwarding WCF service.

Return value:

ForwardedData: An object of type BitSophia.BitVoicerServer.Integration.DataFwdService

.ForwardedData containing the data of the oldest frame (FIFO) sent from a client device. If no frame

is available, it returns null.

public ForwardedData[] ReceiveAll(): Receives all frames available in the DataForwarding WCF

service.

Return value:

ForwardedData[]: An array of type BitSophia.BitVoicerServer.Integration.DataFwdService

.ForwardedData containing all frames sent from client devices. If no frame is available, it returns an

empty array.




public bool Send(byte[] serialNumber, byte data): Sends one byte to the specified device.

Parameters:

byte[] serialNumber: A byte array containing the serial number of the device to which to send

data.

byte data: The byte to be wrapped into a BVSP frame and sent to the specified device.

Return value:

bool: True if the sending is successful. Otherwise, false.

bool Send(byte[] serialNumber, Int16 data): Sends one Int16 to the specified device.

Parameters:


data.

Int16 data: The Int16 to be wrapped into a BVSP frame and sent to the specified device.

Return value:


bool Send(byte[] serialNumber, int data): Sends one int to the specified device.

Parameters:


data.

int data: The int to be wrapped into a BVSP frame and sent to the specified device.

Return value:


bool Send(byte[] serialNumber, string data): Sends one string to the specified device.

Parameters:


data.

string data: The string to be wrapped into a BVSP frame and sent to the specified device.

Return value:


bool Send(byte[] serialNumber, byte[] data): Sends one byte array to the specified device.




Parameters:


data.

byte[] data: The byte array to be wrapped into a BVSP frame and sent to the specified device.

Return value:


bool Send(byte[] serialNumber, BVSPFrame frame): Sends one BVSP frame to the specified device.

Parameters:


data.

BVSPFrame frame: The object of type BitSophia.BitVoicerServer.Integration.DataFwdService

.BVSPFrame to be sent to the specified device.

Return value:


void Start(): Starts monitoring for available frames. The DataReceived event is only raised after the

DataForwardingMonitor is started.

void Stop(): Stops monitoring for available frames. When the DataForwardingMonitor is stopped, the

DataReceived event is not raised.

void Unbind(byte[] serialNumber): Dissociates the current instance of the DataForwardingMonitor from

a client device.

Parameters:

byte[] serialNumber: A byte array containing the serial number of the device from which to

unbind.

EVENTS

public event DataReceivedEventHandler DataReceived: Occurs when one or more frames are received

by the DataForwardingMonitor. This event is raised on a thread from the system-thread pool.




public event FaultedEventHandler Faulted: Occurs when an exception is thrown in the thread that

monitors for available frames. This event is raised on a thread from the system-thread pool.

REMARKS:

The DataForwardingMonitor class uses an internal timer to control at which frequency the server

must be queried for available frames after the Start() method is called. The default query interval is 500

milliseconds (half a second). Using shorter intervals will increase the consumption of server resources.

Even if the SynchronizingObject property is not null, the DataReceived and Faulted events can occur

after the Stop() or Dispose() method has been called. It happens because the signal to raise these events

is always queued for execution on a thread pool thread. One way to resolve this race condition is to set a

flag that tells the event handlers for the DataReceived and Faulted events to ignore subsequent events.

The DataForwardingMonitor class supports simultaneous binding with multiple devices through

multiple calls to the Bind(byte[] serialNumber) method.

Always call the Dispose() method before you release the last reference to this class.

7.1.1.2 DataReceivedEventArgs Class

DESCRIPTION:

Provides information about the DataReceived event of the DataForwardingMonitor class.

SINTAX:

public class DataReceivedEventArgs : EventArgs

CONSTRUCTORS:

public DataReceivedEventArgs(): Initializes a new instance of the DataReceivedEventArgs class.

public DataReceivedEventArgs(ForwardedData[] forwardedData): Initializes a new instance of the

DataReceivedEventArgs class, and sets the specified array to the ForwardedData property.

Parameters:

ForwardedData[] forwardedData: The array of type BitSophia.BitVoicerServer.Integration

.DataFwdService.ForwardedData containing all frames sent from client devices.




PROPERTIES:

public ForwardedData[] ForwardedData: Gets or sets the array of type BitSophia.BitVoicerServer

.Integration.DataFwdService.ForwardedData containing all frames sent from client devices.

7.1.1.3 ExtensionMethods Class

DESCRIPTION:

Provides extension methods to classes in the BitSophia.BitVoicerServer.Integration namespace.

METHODS:

internal static byte[] ToISO88591ByteArray(this string text): Returns a byte array (ISO 8859-1)

from a string. This method can be used to create the BVSFrame payload when its data type is string.

internal static string ToISO88591String(this byte[] byteArray): Returns a string from an encoded

byte array (ISO 8859-1). This method can be used to retrieve the string encoded in the BVSFrame

payload.

public static byte PayloadToByte(this ForwardedData fwdData): Returns the byte contained in the

ForwardedData payload when its data type is byte.

public static Int16 PayloadToInt16(this ForwardedData fwdData): Returns the Int16 contained in

the ForwardedData payload when its data type is Int16.

public static int PayloadToInt32(this ForwardedData fwdData): Returns the int contained in the

ForwardedData payload when its data type is int.

public static byte[] PayloadToBinary(this ForwardedData fwdData): Returns the byte array

contained in the ForwardedData payload when its data type is Binary.

public static string PayloadToString(this ForwardedData fwdData): Returns the string contained in

the ForwardedData payload when its data type is string.




7.1.1.4 FaultedEventArgs Class

DESCRIPTION:

Provides information about the Faulted event of the DataForwardingMonitor and the SpeechMonitor

classes.

SINTAX:

public class FaultedEventArgs : EventArgs

CONSTRUCTORS:

public FaultedEventArgs(): Initializes a new instance of the FaultedEventArgs class.

public FaultedEventArgs(Exception ex): Initializes a new instance of the FaultedEventArgs class, and

sets the specified Exception to the Exception property.

Parameters:

Exception ex: The object of type System.Exception containing information about the error that

raised the Faulted event of the DataForwardingMonitor and the SpeechMonitor classes.

PROPERTIES:

public Exception Exception: Gets or sets the System.Exception that raised the Faulted event of the

DataForwardingMonitor and the SpeechMonitor classes.

7.1.1.5 RecognitionResultEventArgs Class

DESCRIPTION:

Provides information about the SpeechRecognized and SpeechRejected events of the

SpeechMonitor class.

SINTAX:

public class RecognitionResultEventArgs : EventArgs




CONSTRUCTORS:

public RecognitionResultEventArgs(): Initializes a new instance of the RecognitionResultEventArgs

class.

public RecognitionResultEventArgs (BVSRecognitionResult recognitionResult): Initializes a new

instance of the RecognitionResultEventArgs class, and sets the specified BVSRecognitionResult to

the Result property.

Parameters:

BVSRecognitionResult recognitionResult: The object of type BitSophia.BitVoicerServer

.Integration.SpeechInterfaceService.BVSRecognitionResult containing information about the

SpeechRecognized or SpeechRejected event of the SpeechMonitor class.

PROPERTIES:

public BVSRecognitionResult Result: Gets or sets the object of type BitSophia.BitVoicerServer

.Integration.SpeechInterfaceService.BVSRecognitionResult containing information about the

SpeechRecognized or SpeechRejected event of the SpeechMonitor class.

7.1.1.6 SpeechMonitor Class

DESCRIPTION:

Wraps and extends the WCF services of the Speech Manager Module.

SINTAX:

public class SpeechMonitor : IDisposable

CONSTRUCTORS:

public SpeechMonitor(): Initializes a new instance of the SpeechMonitor class using default settings.

public SpeechMonitor(double refreshInterval): Initializes a new instance of the SpeechMonitor class

using the specified refresh interval.




Parameters:

double refreshInterval: The interval, in milliseconds, at which the SpeechMonitor verifies if there

are available recognition results on the server. The minimum value for this parameter is 100

milliseconds.

public SpeechMonitor(int port): Initializes a new instance of the SpeechMonitor class using the

specified port.

Parameters:

int port: The port in which the SpeechInterface WCF service is listening.

public SpeechMonitor(double refreshInterval, int port): Initializes a new instance of the

SpeechMonitor class using the specified refresh interval and port.

Parameters:

double refreshInterval: The interval, in milliseconds, at which the SpeechMonitor verifies if there

are available recognition results on the server. The minimum value for this parameter is 100

milliseconds.

int port: The port in which the SpeechInterface WCF service is listening.

PROPERTIES

public bool IsRunning: Gets a value that indicates whether the SpeechMonitor is checking if there are

available recognition results on the server.

public bool IsConnected: Gets a value that indicates whether the SpeechMonitor is connected to the

SpeechInterface service.

public bool IsDisposed: Gets a value that indicates whether the SpeechMonitor has been disposed of.

public ISynchronizeInvoke SynchronizingObject: Gets or sets the object used to marshal event-

handler calls that are issued when the Faulted, SpeechRecognized and SpeechRejected events

occur.




Remarks:

By default, the methods that handle the Faulted, SpeechRecognized and SpeechRejected events

are called on a thread from the system-thread pool. When these events are handled by a visual

Windows Forms component, such as a form, accessing the component through the system-thread

pool might result in an exception or just might not work. Avoid this effect by setting

SynchronizingObject to a Windows Forms component, which causes the methods that handle the

Faulted, SpeechRecognized and SpeechRejected events to be called on the same thread that the

component was created on.

METHODS:

public void Connect(): Connects the SpeechMonitor to the SpeechInterface WCF service.

public void Disconnect(): Disconnects the SpeechMonitor from the SpeechInterface WCF service.

public void Dispose(): Releases all resources used by the current instance of the SpeechMonitor class.

Always call this method before you release the last reference to this class.

protected virtual void Dispose(bool disposing): Releases the unmanaged resources used by the

SpeechMonitor class, and optionally disposes of the managed resources.

Parameters:

bool disposing: True to release both managed and unmanaged resources; false to releases only

unmanaged resources.

public Device[] GetRecognitionClients(): Returns a Device array containing all active recognition

clients (those to which a SRE has been assigned).

Return value:

Device[]: An array of type BitSophia.BitVoicerServer.Integration.SpeechInterfaceService.Device

containing all devices to which a SRE has been assigned or an empty array if no device is found.

public BVSRecognitionResult[] GetRecognitionResults(): Retrieves all speech recognition results

available in the SpeechInterface WCF service.




Return value:

BVSRecognitionResult[]: An array of type BitSophia.BitVoicerServer.Integration

.SpeechInterfaceService.BVSRecognitionResult containing all speech recognition results available

on the server. If no recognition result is available, it returns an empty array.

public SREStatus GetSREStatus(byte[] serialNumber): Retrieves the most recent status of the SRE

assigned to the specified device.

Parameters:

byte[] serialNumber: A byte array containing the serial number of the device from which to get

the SRE status.

Return value:

SREStatus: An object of type BitSophia.BitVoicerServer.Integration.SpeechInterfaceService

.SREStatus containing information about the current status of the SRE assigned to the specified

device. If the device does not have a SRE, it returns null.

public SREStatus GetSREStatus(int deviceID): Retrieves the most recent status of the SRE assigned

to the specified device.

Parameters:

int deviceID: The ID of the device from which to get the SRE status.

Return value:




public void PlaySpeech(string text): Synthesizes and reproduces the specified text using the

SystemSpeaker device present in the solution. If no SystemSpeaker device is found, no audio is

reproduced.

Parameters:

string text: The character sequence to be synthesized.

public bool SendSpeech(string text, byte[] serialNumber): Synthesizes the specified text and

sends it to the client device as an audio stream (section 6.3.2 Stream Mode).




Parameters:


byte[] serialNumber: A byte array containing the serial number of the device to which to send the

synthesized speech.

Return value:

bool: True if the device was found and the audio queued for transmission. Otherwise, false.

public void Start(): Starts monitoring for available recognition results. The SpeechRecognized and

SpeechRejected events are only raised after the SpeechMonitor is started.

public void Stop(): Stops monitoring for available recognition results. When the SpeechMonitor is

stopped, the SpeechRecognized and SpeechRejected events are not raised.

EVENTS:

public event FaultedEventHandler Faulted: Occurs when an exception is thrown in the thread that

monitors for available recognition results. This event is raised on a thread from the system-thread

pool.

public event RecognitionResultEventHandler SpeechRecognized: Occurs when the SpeechMonitor

identifies one or more valid recognition results (section 3.1.3.2 Validation Filters). This event is raised

on a thread from the system-thread pool.

public event RecognitionResultEventHandler SpeechRejected: Occurs when the SpeechMonitor

identifies one or more invalid recognition results (seção 3.1.3.2 Validation Filters). This event is raised

on a thread from the system-thread pool.

REMARKS:

The SpeechMonitor class uses an internal timer to control at which frequency the server must be

queried for available recognition results after the Start() method is called. The default query interval is 500

milliseconds (half a second). Using shorter intervals will increase the consumption of server resources.

Even if the SynchronizingObject property is not null, the SpeechRecognized, SpeechRejected and

Faulted events can occur after the Stop() or Dispose() method has been called. It happens because the

signal to raise these events is always queued for execution on a thread pool thread. One way to resolve this




race condition is to set a flag that tells the event handlers for the SpeechRecognized, SpeechRejected and

Faulted events to ignore subsequent events.

Always call the Dispose() method before you release the last reference to this class.

7.1.1.7 DataReceivedEventHandler Delegate

DESCRIPTION:

Represents the method that will handle the DataReceived event of the DataForwardingMonitor class.

SINTAX:

public delegate void DataReceivedEventHandler( object sender, DataReceivedEventArgs e)

7.1.1.8 FaultedEventHandler Delegate

DESCRIPTION:

Represents the method that will handle the Faulted event of the DataForwardingMonitor and

SpeechMonitor classes.

SINTAX:

public delegate void FaultedEventHandler( object sender, FaultedEventArgs e)

7.1.1.9 RecognitionResultEventHandler Delegate

DESCRIPTION:

Represents the method that will handle the SpeechRecognized and SpeechRejected events of the

SpeechMonitor class.

SINTAX:

public delegate void RecognitionResultEventHandler( object sender, RecognitionResultEventArgs e)

7.1.1.10 RejectionReason Enumeration

DESCRIPTION:

Specifies the reasons why a speech recognition can be considered invalid (section 3.1.3.2 Validation

Filters).




SINTAX:

public enum RejectionReason

MEMBERS:

None No reason to reject the recognition. Valid recognition.

LowConfidenceLevel Low confidence level.

LowAudioLevel Low audio level.

InLatencyPeriod Inside the latency period.

ActWordNotRecognized The activation word has not been recognized.

7.1.2 BitSophia.BitVoicerServer.Integration.SpeechInterfaceService

The BitSophia.BitVoicerServer.Integration.SpeechInterfaceService namespace contains types

generated from the metadata exposed by the SpeechInterface service (section 3.1.3.5 Speech Manager).

7.1.2.1 BVSRecognitionResult Class

DESCRIPTION:

Contains detailed information about recognitions performed by SREs.

SINTAX:

[SerializableAttribute()] public partial class BVSRecognitionResult : IExtensibleDataObject, INotifyPropertyChanged PROPERTIES:

public DateTime ActWordRecognitionTime: Gets or sets the moment at which the activation word was

recognized.

public int AudioLevel: Gets or sets the audio level (volume from 0 to 100) at the moment of recognition.




public double AudioLevelAvg: Gets or sets the audio level average at the moment of recognition.

public int AudioLevelTrigger: Gets or sets the audio level (volume from 0 to 100) that started the audio-

level-activated period.

public double AudioLevelTriggerAvg: Gets or sets the audio level average at the moment the audio-

level-activated period started.

public float ConfidenceLevel: Gets or sets a value (0 to 1), estimated by the SRE, that represents the

relative probability of the recognized speech being the correct match among the alternative

possibilities.

public int InputDeviceID: Gets or sets the ID of the device that captured the audio stream.

public int InputDeviceLocationID: Gets or sets the location ID of the device that captured the audio

stream.

public string InputDeviceName: Gets or sets the name of the device that captured the audio stream.

public byte[] InputDeviceSerialNumber: Gets or sets the serial number of the device that captured the

audio stream.

public bool IsActivationWordOnly: Gets or sets a value that indicates whether the recognized speech

corresponds to an activation word only.

public DateTime LatencyStartTime: Gets or sets the moment at which the latency period started.

public DateTime RecognitionTime: Gets or sets the moment of recognition.




public int RejectionReason: Gets or sets a value that indicates the reason why the recognition was

rejected (section 7.1.1.10 RejectionReason).

public string Text: Gets or sets the text recognized by the SRE.

7.1.2.2 Command Class

DESCRIPTION:

Represents a command in a BitVoicer Server Solution. Commands are executed by the server in

response to valid recognitions or device events (section 4.1.2.4 Cues).

SINTAX:

[SerializableAttribute()] public partial class Command : BitSophia.BitVoicerServer.Integration.SpeechInterfaceService.SolutionObject

PROPERTIES:

public byte Action: Gets or sets what action must be taken by the command:

0 = RunExecutable

1 = PlayAudio

2 = SendData

public byte AudioSource: Gets or sets the audio source of PlayAudio commands:

0 = Synthesizer

1 = WaveFile

public int BinaryDataID: Gets or sets the ID of the Binary Data object that contains the data sent by

SendData commands.

public string Data: Gets or sets the textual representation of the data sent by SendData commands (only

when the data type is not Binary).




public byte DataType: Gets or sets the type of the data sent by SendData commands:

0 = NA

1 = Byte

3 = Int16

5 = Int32

7 = Binary

8 = String

public bool LocationSpecific: Gets or sets whether the command should be executed only when the

target device is at the same location of the device that captured the audio (section 4.1.5 Commands).

public string Parameters: Gets or sets the execution parameters used in RunExecutable commands.

public string PlayFilePath: Gets or sets the full path to the .wav file reproduced or streamed by

PlayAudio commands (only when the audio source is WaveFile).

public string RunFilePath: Gets or sets the full path to the file to be executed by RunExecutable

commands.

public string SynthesizedText: Gets or sets the text to be synthesized by PlayAudio commands (only

when the audio source is Synthesizer).

public int TargetDeviceID: Gets or sets the ID of the command target device.

public int TargetDeviceNodeID: Gets or sets ID of the device node that is the final command target.

7.1.2.3 Device Class

DESCRIPTION:

Represents a device in a BitVoicer Server Solution.




SINTAX:

[SerializableAttribute()] public partial class Device : BitSophia.BitVoicerServer.Integration.SpeechInterfaceService.SolutionObject

PROPERTIES:

public Command ActivatedPeriodEndedCue: Gets or sets the command to be executed when the activated

period ends (section 3.1.3.2 Validation Filters).

public Command ActivatedPeriodStartedCue: Gets or sets the command to be executed when the

activated period starts (section 3.1.3.2 Validation Filters).

public int CommInterface: Gets or sets the communication interface used by the device:

0 = NA

1 = SerialCOM

2 = TCPIP

public int DeviceType: Gets or sets the device type:

0 = Input

1 = Output

2 = Mixed

3 = SystemMic

4 = SystemSpeaker

public bool Disabled: Gets or sets a value that indicates whether the device is disabled.

public bool EnableActivatedPeriodEndedCue: Gets or sets a value that indicates whether the command

related to the “End of Activated Period” Cue (section 4.1.2.4 Cues) should be executed.

public bool EnableActivatedPeriodStartedCue: Gets or sets a value that indicates whether the

command related to the “Start of Activated Period” Cue (section 4.1.2.4 Cues) should be executed.




public bool EnableSpeechRejectedCue: Gets or sets a value that indicates whether the command related

to the “Speech Rejected” Cue (section 4.1.2.4 Cues) should be executed.

public int InputBufferSize: Gets or sets the size (bytes) of the input buffer of the device communication

interface.

public int LocationID: Gets or sets the ID of the location where the device is installed.

public int MaxStreamSegmentSize: Gets or sets the maximum size (in bytes) of the binary segments sent

from BitVoicer Server to the client device in each send operation.

public byte MinimumAudioLevel: Gets or sets the minimum audio level (volume from 0 to 100) that must

be reached to validate recognitions performed through the device (section 3.1.3.2 Validation Filters).

public Dictionary<int, DeviceNode> Nodes: Gets or sets the dictionary of nodes present in the device.

public int OutputBufferSize: Gets or sets the size (bytes) of the output buffer of the device

communication interface.

public int OutputProtocol: Gets or sets the protocol used by the device to senddata:

0 = None

1 = BitVoicerServerProtocol

public int OutputRate: Gets or sets the maximum number of bytes per second BitVoicer Server can send

to the device.

public byte[] SerialNumber: Gets or sets the device serial number (UTF-8 encoding).

public SerialSettings SerialSettings: Gets or sets the BitSophia.BitVoicerServer.Integration

.SpeechInterfaceService.SerialSettings object that contains the settings of the device serial port.




public Command SpeechRejectedCue: Gets or sets the command to be executed when speech captured by

the device is rejected (section 3.1.3.2 Validation Filters).

public int SynthesizerVolume: Gets or sets the audio volume (1 to 100) generated by the synthesizer

when synthesized speech must be sent to the device.

public float SystemMicLevel: Gets or sets the microphone level (0 to 1) to be selected in the Windows

settings when the device type is SystemMic.

public float SystemSpeakerLevel: Gets or sets speaker level (0 to 1) to be selected in the Windows

settings when the device type is SystemSpeaker.

public TCPIPSettings TCPIPSettings: Gets or sets the BitSophia.BitVoicerServer.Integration

.SpeechInterfaceService.TCPIPSettings object that contains the device TCP/IP settings.

7.1.2.4 DeviceNode Class

DESCRIPTION:

Represents a device node in a BitVoicer Server Solution.

SINTAX:

[SerializableAttribute()] public partial class DeviceNode : BitSophia.BitVoicerServer.Integration.SpeechInterfaceService.SolutionObject

PROPERTIES:

public bool Disabled: Gets or sets a value that indicates whether the device node is disabled.

public int LocationID: Gets or sets the ID of the location where the device node is installed.




7.1.2.5 SerialSettings Class

DESCRIPTION:

Contains the serial port settings that are used by devices whose communication interface is

SerialCOM.

SINTAX:

[System.SerializableAttribute()] public partial class SerialSettings : IExtensibleDataObject, INotifyPropertyChanged

PROPERTIES:

public int Baud: Gets or sets the baud rate (bits per second) of the serial port.

public int DataBits: Gets or sets the standard length of data bits per byte.

public bool DtrEnabled: Gets or sets whether the Data Terminal Ready (DTR) signal is enabled.

public bool DoNotLock: Gets or sets whether BitVoicer Server should keep the serial port unblocked when

it becomes available.

public int FlowControl: Gets or sets the handshaking protocol for serial port transmission of data:

0 = None

1 = XOnXOff

2 = RequestToSend

3 = RequestToSendXOnXOff

public int Parity: Gets or sets the parity-checking protocol:

0 = None

1 = Odd

2 = Even

3 = Mark

4 = Space




public string PortName: Gets or sets the serial port name (e.g. COM3, COM4, COM201, etc.).

public bool RtsEnabled: Gets or sets whether the Request to Send (RTS) signal is enabled.

public int StopBits: Gets or sets the standard number of stop bits per byte:

0 = None

1 = One

2 = Two

3 = OnePointFive

7.1.2.6 SolutionObject Class

DESCRIPTION:

Represents the base class for the main solution objects (section 4.1 Solution Objects).

SINTAX:

[SerializableAttribute()] public partial class SolutionObject : IExtensibleDataObject, INotifyPropertyChanged

PROPERTIES:

public int ID: Gets or sets the object identification number.

public string Name: Get or sets the object name.

7.1.2.7 SpeechInterfaceClient Class

DESCRIPTION:

Creates a WCF proxy from the metadata exposed by the SpeechInterface service (section 3.1.3.5

Speech Manager).

SINTAX:

public partial class SpeechInterfaceClient : System.ServiceModel .ClientBase<BitSophia.BitVoicerServer.Integration.SpeechInterfaceService .ISpeechInterface>, BitSophia.BitVoicerServer.Integration.SpeechInterfaceService.ISpeechInterface




METHODS:

public Device[] GetRecognitionClients(): Returns a Device array containing all active recognition

clients (those to which a SRE has been assigned).

Return value:

Device[]: An array of type BitSophia.BitVoicerServer.Integration.SpeechInterfaceService.Device

containing all devices to which a SRE has been assigned or an empty array if no device is found.

public BVSRecognitionResult[] GetRecognitionResults(): Retrieves all speech recognition results

available in the SpeechInterface WCF service.

Return value:

BVSRecognitionResult[]: An array of type BitSophia.BitVoicerServer.Integration

.SpeechInterfaceService.BVSRecognitionResult containing all speech recognition results available

on the server. If no recognition result is available, it returns an empty array.

public SREStatus GetSREStatusByID(int deviceID): Retrieves the most recent status of the SRE

assigned to the specified device.

Parameters:

int deviceID: The ID of the device from which to get the SRE status.

Return value:




public SREStatus GetSREStatusBySN(byte[] serialNumber): Retrieves the most recent status of the

SRE assigned to the specified device.

Parameters:

byte[] serialNumber: A byte array containing the serial number of the device from which to get

the SRE status.

Return value:







public void PlaySpeech(string text): Synthesizes and reproduces the specified text using the

SystemSpeaker device present in the solution. If no SystemSpeaker device is found, no audio is

reproduced.

Parameters:


public bool SendSpeech(string text, byte[] serialNumber): Synthesizes the specified text and

sends it to the client device as an audio stream (section 6.3.2 Stream Mode).

Parameters:


byte[] serialNumber: A byte array containing the serial number of the device to which to send the

synthesized speech.

Return value:

bool: True if the device was found and the audio queued for transmission. Otherwise, false.

7.1.2.8 SREStatus Class

DESCRIPTION:

Contains information about the current status of speech recognition engines (SRE).

SINTAX:

[SerializableAttribute()] public partial class SREStatus : IExtensibleDataObject, INotifyPropertyChanged

PROPERTIES:

public int AudioLevel: Gets or sets the most recent audio level (volume from 0 to 100) measured by the

SRE.

public double AudioLevelAvg: Gets or sets the most recent audio level average calculated by the SRE.

public bool IsInAudioLevelActivatedPeriod: Gets or sets a value that indicates whether the SRE is

within the audio-level-activated period.




public bool IsInActWordActivatedPeriod: Gets or sets a value that indicates whether the SRE is within

the activation-word-activated period.

7.1.2.9 TCPIPSettings Class

DESCRIPTION:

Contains the TCP/IP settings that are used by devices whose communication interface is TCPIP.

SINTAX:

[SerializableAttribute()] public partial class TCPIPSettings : IExtensibleDataObject, INotifyPropertyChanged

PROPERTIES:

public int InactivityTimeout: Gets or sets the time interval (in seconds) a device, whose

communication interface is TCP/IP, can remain inactive (without any data exchange) before its

connection is closed and all resources associated with it are discarded.

public byte[] IPAddress: Gets or sets the device IP address (IPv4). Each byte in the array corresponds

to one octet in the IP address.

public int TCPPort: Gets or sets the device TCP port. This property is inactive in the current version of

BitVoicer Server.

7.1.3 BitSophia.BitVoicerServer.Integration.DataFwdService

The BitSophia.BitVoicerServer.Integration.DataFwdService namespace contains types generated

from the metadata exposed by the DataForwarding service (section 3.1.5 Data Forwarding).

7.1.3.1 BVSPFrame Class

DESCRIPTION:

Represents one BVSP frame (section 6.6 BitVoicer Server Protocol) of DataTransfer type.

SINTAX:

[SerializableAttribute()] public partial class BVSPFrame : IExtensibleDataObject, INotifyPropertyChanged




PROPERTIES:

public int DataLength: Gets or sets the number of bytes contained in the Payload property.

public int DataType: Gets or sets the type of data contained in the Payload property:

1 = Byte

3 = Int16

5 = Int32

7 = Binary

8 = String

public byte[] Payload: Gets or sets the byte array that contains the data specified in the DataType

property.

7.1.3.2 Command Class

DESCRIPTION:

Represents a command in a BitVoicer Server Solution. Commands are executed by the server in

response to valid recognitions or device events (section 4.1.2.4 Cues).

SINTAX:

[SerializableAttribute()] public partial class Command : BitSophia.BitVoicerServer.Integration.DataFwdService.SolutionObject

PROPERTIES:

public byte Action: Gets or sets what action must be taken by the command:

0 = RunExecutable

1 = PlayAudio

2 = SendData

public byte AudioSource: Gets or sets the audio source of PlayAudio commands:

0 = Synthesizer

1 = WaveFile




public int BinaryDataID: Gets or sets the ID of the Binary Data object that contains the data sent by

SendData commands.

public string Data: Gets or sets the textual representation of the data sent by SendData commands (only

when the data type is not Binary).

public byte DataType: Gets or sets the type of the data sent by SendData commands:

0 = NA

1 = Byte

3 = Int16

5 = Int32

7 = Binary

8 = String

public bool LocationSpecific: Gets or sets whether the command should be executed only when the

target device is at the same location of the device that captured the audio (section 4.1.5 Commands).

public string Parameters: Gets or sets the parameters used in the execution of RunExecutable

commands.

public string PlayFilePath: Gets or sets the full path to the .wav file reproduced or streamed by

PlayAudio commands (only when the audio source is WaveFile).

public string RunFilePath: Gets or sets the full path to the file to be executed by RunExecutable

commands.

public string SynthesizedText: Gets or sets the text to be synthesized by PlayAudio commands (only

when the audio source is Synthesizer).

public int TargetDeviceID: Gets or sets the ID of the command target device.




public int TargetDeviceNodeID: Gets or sets ID of the device node that is the final command target.

7.1.3.3 DataForwardingClient Class

DESCRIPTION:

Creates a WCF proxy from the metadata exposed by the DataForwarding service (section 3.1.5 Data

Forwarding).

SINTAX:

public partial class DataForwardingClient : System.ServiceModel .ClientBase<BitSophia.BitVoicerServer.Integration.DataFwdService .IDataForwarding>, BitSophia.BitVoicerServer.Integration.DataFwdService.IDataForwarding

METHODS:

public bool Bind(byte[] serialNumber): Associates the current instance of the DataForwardingClient

class with a client device.

Parameters:

byte[] serialNumber: A byte array containing the serial number of the device to which to bind.

Return value:

bool: True if the binding is successful. Otherwise, false.

public int CountActiveBindings(): Returns the number of devices to which the DataForwardingClient is

bound.

Return value:

int: The number of devices to which the DataForwardingClient is bound. If the

DataForwardingClient is not bound to any device, it returns zero.

public int CountAvailableFrames(): Returns the number of available frames sent from devices to which

the DataForwardingClient is bound.

Return value:

int: The number of available frames. If no frame is available or the DataForwardingClient is not

bound to any device, it returns zero.




public Device[] GetSolutionDevices(): Returns a Device array containing all devices present in the

solution.

Return value:

Device[]: An array of type BitSophia.BitVoicerServer.Integration.DataFwdService.Device

containing all devices present in the solution or an empty array if no device is found.

public ForwardedData Receive(): Receives one frame from the DataForwarding WCF service.

Return value:

ForwardedData: An object of type BitSophia.BitVoicerServer.Integration.DataFwdService

.ForwardedData containing the data of the oldest frame (FIFO) sent from a client device. If no frame

is available, it returns null.

public ForwardedData[] ReceiveAll(): Receives all frames available in the DataForwarding WCF

service.

Return value:

ForwardedData[]: An array of type BitSophia.BitVoicerServer.Integration.DataFwdService

.ForwardedData containing all frames sent from client devices. If no frame is available, it returns an

empty array.

public bool Send(byte[] serialNumber, BVSPFrame frame): Sends one BVSP frame to the specified

device.

Parameters:


data.

BVSPFrame frame: The object of type BitSophia.BitVoicerServer.Integration.DataFwdService

.BVSPFrame to be sent to the specified device.

Return value:


public void Unbind(byte[] serialNumber): Dissociates the current instance of the

DataForwardingClient from a client device.




Parameters:

byte[] serialNumber: A byte array containing the serial number of the device from which to

unbind.

7.1.3.4 Device Class

DESCRIPTION:

Represents a device in a BitVoicer Server Solution.

SINTAX:

[SerializableAttribute()] public partial class Device : BitSophia.BitVoicerServer.Integration.DataFwdService.SolutionObject

PROPERTIES:

public Command ActivatedPeriodEndedCue: Gets or sets the command to be executed when the activated

period ends (section 3.1.3.2 Validation Filters).

public Command ActivatedPeriodStartedCue: Gets or sets the command to be executed when the

activated period starts (section 3.1.3.2 Validation Filters).

public int CommInterface: Gets or sets the communication interface used by the device:

0 = NA

1 = SerialCOM

2 = TCPIP

public int DeviceType: Gets or sets the device type:

0 = Input

1 = Output

2 = Mixed

3 = SystemMic

4 = SystemSpeaker

public bool Disabled: Gets or sets a value that indicates whether the device is disabled.




public bool EnableActivatedPeriodEndedCue: Gets or sets a value that indicates whether the command

related to the “End of Activated Period” Cue (section 4.1.2.4 Cues) should be executed.

public bool EnableActivatedPeriodStartedCue: Gets or sets a value that indicates whether the

command related to the “Start of Activated Period” Cue (section 4.1.2.4 Cues) should be executed.

public bool EnableSpeechRejectedCue: Gets or sets a value that indicates whether the command related

to the “Speech Rejected” Cue (section 4.1.2.4 Cues) should be executed.

public int InputBufferSize: Gets or sets the size (bytes) of the input buffer of the device communication

interface.

public int LocationID: Gets or sets the ID of the location where the device is installed.

public int MaxStreamSegmentSize: Gets or sets the maximum size (in bytes) of the binary segments sent

from BitVoicer Server to the client device in each send operation.

public byte MinimumAudioLevel: Gets or sets the minimum audio level (volume from 0 to 100) that must

be reached to validate recognitions performed through the device (section 3.1.3.2 Validation Filters).

public Dictionary<int, DeviceNode> Nodes: Gets or sets the dictionary of nodes present in the device.

public int OutputBufferSize: Gets or sets the size (bytes) of the output buffer of the device

communication interface.

public int OutputProtocol: Gets or sets the protocol used by the device to receive data:

0 = None

1 = BitVoicerServerProtocol




public int OutputRate: Gets or sets the maximum number of bytes per second BitVoicer Server can send

to the device.

public byte[] SerialNumber: Gets or sets the device serial number (UTF-8 encoding).

public SerialSettings SerialSettings: Gets or sets the BitSophia.BitVoicerServer.Integration

.DataFwdService.SerialSettings object that contains the settings of the device serial port.

public Command SpeechRejectedCue: Gets or sets the command to be executed when speech captured by

the device is rejected (section 3.1.3.2 Validation Filters).

public int SynthesizerVolume: Gets or sets the audio volume (1 to 100) generated by the synthesizer

when synthesized speech must be sent to the device.

public float SystemMicLevel: Gets or sets the microphone level (0 to 1) to be selected in the Windows

settings when the device type is SystemMic.

public float SystemSpeakerLevel: Gets or sets speaker level (0 to 1) to be selected in the Windows

settings when the device type is SystemSpeaker.

public TCPIPSettings TCPIPSettings: Gets or sets the BitSophia.BitVoicerServer.Integration

.DataFwdService.TCPIPSettings object that contains the device TCP/IP settings.

7.1.3.5 Device Node Class

DESCRIPTION:

Represents a device node in a BitVoicer Server Solution.

SINTAX:

[SerializableAttribute()] public partial class DeviceNode : BitSophia.BitVoicerServer.Integration.DataFwdService.SolutionObject




PROPERTIES:

public bool Disabled: Gets or sets a value that indicates whether the device node is disabled.

public int LocationID: Gets or sets the ID of the location where the device node is installed.

7.1.3.6 ForwardedData Class

DESCRIPTION:

Represents one BVSP frame (section 6.6 BitVoicer Server Protocol) that also contains information

about the device that sent the frame.

SINTAX:

[SerializableAttribute()] public partial class ForwardedData : BitSophia.BitVoicerServer.Integration.DataFwdService.BVSPFrame

PROPERTIES:

public string SourceDeviceName: Gets or sets the name of the device that sent the frame.

public byte[] SourceDeviceSerialNumber: Gets or sets the serial number of the device that sent the

frame.

7.1.3.7 SerialSettings Class

DESCRIPTION:

Contains the serial port settings that are used by devices whose communication interface is

SerialCOM.

SINTAX:

[System.SerializableAttribute()] public partial class SerialSettings : IExtensibleDataObject, INotifyPropertyChanged

PROPERTIES:

public int Baud: Gets or sets the baud rate (bits per second) of the serial port.




public int DataBits: Gets or sets the standard length of data bits per byte.

public bool DtrEnabled: Gets or sets whether the Data Terminal Ready (DTR) signal is enabled.

public bool DoNotLock: Gets or sets whether BitVoicer Server should keep the serial port unblocked when

it becomes available.

public int FlowControl: Gets or sets the handshaking protocol for serial port transmission of data:

0 = None

1 = XOnXOff

2 = RequestToSend

3 = RequestToSendXOnXOff

public int Parity: Gets or sets the parity-checking protocol:

0 = None

1 = Odd

2 = Even

3 = Mark

4 = Space

public string PortName: Gets or sets the serial port name (e.g. COM3, COM4, COM201, etc.).

public bool RtsEnabled: Gets or sets whether the Request to Send (RTS) signal is enabled.

public int StopBits: Gets or sets the standard number of stop bits per byte:

0 = None

1 = One

2 = Two

3 = OnePointFive




7.1.3.8 SolutionObject Class

DESCRIPTION:

Represents the base class for the main solution objects (section 4.1 Solution Objects).

SINTAX:

[SerializableAttribute()] public partial class SolutionObject : IExtensibleDataObject, INotifyPropertyChanged

PROPERTIES:

public int ID: Gets or sets the object identification number.

public string Name: Get or sets the object name.

7.1.3.9 TCPIPSettings Class

DESCRIPTION:

Contains the TCP/IP settings that are used by devices whose communication interface is TCPIP.

SINTAX:

[SerializableAttribute()] public partial class TCPIPSettings : IExtensibleDataObject, INotifyPropertyChanged

PROPERTIES:

public int InactivityTimeout: Gets or sets the time interval (in seconds) a device, whose

communication interface is TCP/IP, can remain inactive (without any data exchange) before its

connection is closed and all resources associated with it are discarded.

public byte[] IPAddress: Gets or sets the device IP address (IPv4). Each byte in the array corresponds

to one octet in the IP address.

public int TCPPort: Gets or sets the device TCP port. This property is inactive in the current version of

BitVoicer Server.




7.2 Arduino Libraries

The Arduino libraries are located in the “Libraries\Arduino” folder inside the BitVoicer Server

installation folder (usually C:\Program Files\BitSophia\BitVoicer Server).

To install these libraries in the Arduino development environment (IDE), follow the instructions

available at http://www.arduino.cc/en/Guide/Libraries.

7.2.1 BVSP

The BVSP library provides all necessary resources to exchange information with BitVoicer Server.

The BVSP class, which is present in the library, fully implements the BitVoicer Server Protocol so the user

does not have to know all the details of the protocol in order to interact with the server. This class employs

an event-driven programming model that simplifies the code structure and facilitates the retrieval of data sent

from the server.

7.2.1.1 BVSP Class

DESCRIPTION:

Implements the BitVoicer Server Protocol and provides a set of functions, members and events for

data exchange, status retrieval and connection maintenance.

CONSTRUCTORS:

public BVSP(): Initializes a new instance of the BVSP class.

MEMBERS:

byte inboundMode: Gets the operating mode of the inbound (Device Server) communication channel.

The value of this member reflects the mode defined through the setInboundMode(byte mode)

function:

0x00 = Framed mode

0x01 = Stream mode

boolean isReceiving: Gets a value that indicates if the receive() function is currently reading the serial

port buffer or processing received data:

True = is receiving

False = is not receiving


http://www.arduino.cc/

http://www.arduino.cc/en/Guide/Libraries



byte outboundMode: Gets the operating mode of the outbound (Server Device) communication channel.

The operating mode of the outbound channel is controlled by the server:

0x00 = Framed mode

0x01 = Stream mode

volatile int usedMemory: Gets how many bytes of the internal buffer are currently in use. The default size

of the internal buffer is 64 bytes.

FUNCTIONS:

void begin(Stream &serialPort, unsigned long statusRequestTimeout, unsigned long

statusRequestInterval): Defines the serial port used for communications, the time period for a

status request to expire and the frequency of status requests.

Parameters:

Stream &serialPort: One of the Serial classes that represent serial ports in the Arduino platform

(e.g. Serial, Serial1, Serial2, Serial3).

unsigned long statusRequestTimeout: The time period, in milliseconds, for a status request to

expire. If the server does not respond to a status request within this interval, the function

hasStatusTimedOut() will start returning true and the functions isBVSRunning(),

isDataFwdRunning() and isSREAvailable() will start returning false.

unsigned long statusRequestInterval: Defines how often, in milliseconds, calls to the

keepAlive() function will lead to status requests.

Remarks:

The begin function must be called before any other function of the BVSP class.

The serial port specified in the serialPort parameter must be used exclusively by the BVSP class.

If other applications running on the server must exchange data using the same port, the developer

must do it through the Data Forwarding Module.

byte getReceivedByte(): Returns the last byte received by the BVSP class. This function must be called

only from the frameReceived event handler to retrieve the byte contained in the frame.

Return value:

byte: The last byte received through calls to the receive function. If the type of the received data is

not of byte type, the returned value will be zero. If this function is called outside the frameReceived

event handler, the returned value is undetermined.




int getReceivedBytes(byte *buffer, int bufferSize): Copies the last bytes received by the

BVSPclass into the buffer passed to the function. This function must be called only from the

frameReceived event handler to retrieve the byte array contained in the frame.

Parameters:

byte *buffer: The byte array into which the data shall be copied.

int bufferSize: The size of the buffer passed to the function.

Return value:

int: The number of bytes copied into the buffer. If the type of the received data is not of binary type,

the returned value will be zero. If this function is called outside the frameReceived event handler,

the returned value is undetermined.

int getReceivedBytes(byte *buffer, int bufferSize, int offset, int count): Copies the last

bytes received by the BVSPclass into the buffer passed to the function. This function must be called

only from the frameReceived event handler to retrieve the byte array contained in the frame.

Parameters:

byte *buffer: The byte array into which the data shall be copied.


int offset: The location in the buffer to which to begin coping data.

int count: The number of bytes to be copied.

Return value:

int: The number of bytes copied into the buffer. If the type of the received data is not of binary type,

the returned value will be zero. If this function is called outside the frameReceived event handler,

the returned value is undetermined.

int getReceivedInt16(): Returns the last 16-bit integer received by the BVSP class. This function must be

called only from the frameReceived event handler to retrieve the Int16 contained in the frame.

Return value:

int: The last Int16 received through calls to the receive function. If the type of the received data is

not of Int16 type, the returned value will be zero. If this function is called outside the

frameReceived event handler, the returned value is undetermined.

long getReceivedInt32(): Returns the last 32-bit integer received by the BVSP class. This function must

be called only from the frameReceived event handler to retrieve the Int32 contained in the frame.




Return value:

long: The last Int32 received through calls to the receive function. If the type of the received data

is not of Int32 type, the returned value will be zero. If this function is called outside the

frameReceived event handler, the returned value is undetermined.

int getReceivedStream(byte *buffer, int bufferSize): Copies the last audio samples received by the

BVSPclass into the buffer passed to the function. This function must be called only from the

streamReceived event handler to retrieve the byte array corresponding to the received audio stream.

Parameters:

byte *buffer: The byte array into which the samples shall be copied.


Return value:

int: The number of samples copied into the buffer. If there is no audio stream present in the

internal buffer, the returned value will be zero. If this function is called outside the streamReceived


int getReceivedStream(short *buffer, int bufferSize): Copies the last audio samples received by

the BVSPclass into the buffer passed to the function. This function must be called only from the

streamReceived event handler to retrieve the byte array corresponding to the received audio stream.

Parameters:

short *buffer: The short array (16-bit signed integer) into which the samples shall be copied.


Return value:




int getReceivedStream(byte *buffer, int bufferSize, int offset, int count): Copies the last

audio samples received by the BVSPclass into the buffer passed to the function. This function must

be called only from the streamReceived event handler to retrieve the byte array corresponding to the

received audio stream.




Parameters:

byte *buffer: The byte array into which the samples shall be copied.


int offset: The location in the buffer to which to begin coping samples.

int count: The number of samples to be copied.

Return value:




int getReceivedStream(short *buffer, int bufferSize, int offset, int count): Copies the last

audio samples received by the BVSPclass into the buffer passed to the function. This function must

be called only from the streamReceived event handler to retrieve the byte array corresponding to the

received audio stream.

Parameters:

short *buffer: The short array (16-bit signed integer) into which the samples shall be copied.


int offset: The location in the buffer to which to begin coping samples.

int count: The number of samples to be copied.

Return value:




int getReceivedString(char *buffer, int bufferSize): Returns the last string (char array) received by

the BVSP class. This function must be called only from the frameReceived event handler to retrieve

the string contained in the frame.

Parameters:

char *buffer: The char array into which the string shall be copied.


Return value:

int: The number of characters copied into the buffer. If the type of the received data is not of string

type, the returned value will be zero. If this function is called outside the frameReceived event

handler, the returned value is undetermined.




boolean hasStatusTimedOut(): Returns a value that indicates whether the last status request performed

through the requestStatus function has expired.

Return value:

boolean: True if the status request has expired. Otherwise, false.

Remarks:

To determine if the last status request has expired, this function uses the statusRequestTimeout

parameter passed to the begin function.

boolean isBVSRunning(): Returns a value that indicates whether BitVoicer Server is running.

Return value:

Boolean: True if BitVoicer Server is running. Otherwise, false.

Remarks:

This function does not perform queries to the server. For it to return true, a status request frame

must be sent to the server through the requestStatus or keepAlive function. If the last status

request has timed out (refer to the begin function), this function will return false.

boolean isDataFwdRunning(): Returns a value that indicates whether the Data Forwarding Module is

running.

Return value:

Boolean: True if the Data Forwarding is running. Otherwise, false.

Remarks:




boolean isSREAvailable(): Returns a value that indicates whether there is a speech recognition engine

assigned to the device (section 3.1.3.1 Speech Recognition Engine Assignment).

Return value:

Boolean: true if there is a speech recognition engine assigned to the device. Otherwise, false.

Remarks:







void keepAlive(): Keeps the client device active and requests a status frame to the server.

Remarks:

This function verifies if the status request interval (refer to the begin function) has elapsed before

performing requests to the server. If this interval has not yet elapsed, no request is sent.

void receive(): Verifies if there is data available in the serial port and process the received data according

to the specifications of the BitVoicer Server Protocol.

Remarks:

This function can raise the frameReceived, modeChanged or streamReceived event depending on

the data received from the server. Event handlers must be set to these events in order to retrieve

the received data.

void requestStatus(): Sends a status request frame to the server and marks the moment at which the

frame was sent.

Remarks:

To get the response values sent from the server, use the isBVSRunning, isDataFwdRunning and

isSREAvailable functions.

void reset(): Discards all data from the internal buffer and returns the BVSP class to its original state.

The parameters passed to the begin function are not discarded.

void send(byte data): Wraps the specified byte into a BVSP frame (section 6.6 BitVoicer Server Protocol

Frame Structure) and sends it to the Data Forwarding Module.

Parametros:

byte data: The byte (8-bit unsigned integer) to be sent to the Data Forwarding Module.

void send(int data): Wraps the specified int into a BVSP frame (section 6.6 BitVoicer Server Protocol


Parameters:

int data: The int (16-bit signed integer) to be sent to the Data Forwarding Module.




void send(long data): Wraps the specified long into a BVSP frame (section 6.6 BitVoicer Server Protocol


Parameters:

long data: The long (32-bit signed integer) to be sent to the Data Forwarding Module.

void send(byte *data, int count): Wraps the specified byte array into a BVSP frame (section 6.6

BitVoicer Server Protocol Frame Structure) and sends it to the Data Forwarding Module.

Parameters:

byte *data: The byte array to be sent to the Data Forwarding Module.

int count: The number of bytes to be sent from position zero.

void send(byte *data, int offset, int count): Wraps the specified byte array into a BVSP frame

(section 6.6 BitVoicer Server Protocol Frame Structure) and sends it to the Data Forwarding Module.

Parameters:

byte *data: The byte array that contains the data to be sent to the Data Forwarding Module.

int offset: The position in the buffer from which to begin sending data.

int count: The number of bytes to be sent.

void send(char *data): Wraps the specified string (char array) into a BVSP frame (section 6.6 BitVoicer

Server Protocol Frame Structure) and sends it to the Data Forwarding Module.

Parameters:

char *data: The string (char array) to be sent to the Data Forwarding Module.

void sendStream(byte *data, int count): Sends the specified audio stream to the speech recognition

engine assigned to the device (section 3.1.3.1 Speech Recognition Engine Assignment).

Parameters:

byte *data: The audio stream (byte array) to be sent to the speech recognition engine.

int count: The number of samples to be sent from position zero.

Remarks:

The inbound (Device Server) communication channel must be operating in stream mode (section

6.3.2 Stream Mode) for BitVoicer Server to route the audio streams to a speech recognition engine.

To alter the operating mode of the inbound channel, use the setInboundMode function.




void setInboundMode(byte mode): Alters the operating mode (section 6.3 Basic Concepts) of the inbound

communication channel (Device Server).

Parameters:

byte mode: A byte that indicates what should be the operating mode of the inbound channel. The

following constants can be used on calls to this function:

o FRAMED_MODE = 0x00

o STREAM_MODE = 0x01

Remarks:

The initial operating mode of the inbound communication channel is Framed.

To send data to the Data Forwarding Module, the inbound channel must be operating in framed

mode.

To send audio streams to Speech Recognition Engines, the inbound channel must be operating in

stream mode.

EVENTS:

FrameReceivedPtr frameReceived: Occurs when the receive function identifies that a BVSP frame

(section 6.6 BitVoicer Server Protocol) has been received from the server.

ModeChangedPtr modeChanged: Occurs when the receive function identifies that a request to alter the

operating mode of the outbound channel (section 6.5.2 Changing the Operating Mode) has been

received from the server.

StreamReceivedPtr streamReceived: Occurs when the receive function identifies that an audio stream

segment (section 6.3.2 Stream Mode) has been received from the server.

REMARKS:

The BVSP class uses an internal buffer to process frames and audio streams received from the

server. The size of this buffer is determined by the BVSP_BUFFER_SIZE constant defined in the BVSP.h file

and its default value is 64 (bytes). In case the BVSP class receives frames whose length is greater than 64

bytes (e.g. a frame containing a string with more than 60 characters), the size of its buffer must be increased

so that it is able to hold the whole frame (section 6.6 BitVoicer Server Protocol).

Client devices that use TCP/IP communication interfaces must maintain an active connection with

the server (section 6.4.1 TCP/IP). The keepAlive function, along with the parameters passed to the begin

function, provides the resources to keep this connection active. Even though the keepAlive function is




especially useful for TCP/IP devices, it can be used by any type of device to keep the status information

(refer to the isBVSRunning, isDataFwdRunning and isSREAvailable functions) updated.

7.2.1.2 Constants

#define BVSP_BUFFER_SIZE 64

#define DATA_TYPE_NA 0x00

#define DATA_TYPE_BYTE 0x01

#define DATA_TYPE_INT16 0x03

#define DATA_TYPE_INT32 0x05

#define DATA_TYPE_BINARY 0x07

#define DATA_TYPE_STRING 0x08

#define DATA_TYPE_STATUS 0x0F

#define FRAMED_MODE 0x00

#define STREAM_MODE 0x01

7.2.1.3 FrameReceivedPtr Type

DESCRIPTION:

Defines a function pointer for the function that will handle the frameReceived event of the BVSP

class.

SINTAX:

typedef void (*FrameReceivedPtr)(byte, int)

PARAMETERS:

byte: The type of data contained in the frame payload:

o 1 = Byte

o 3 = Int16

o 5 = Int32

o 7 = Binary

o 8 = String




int: The size, in bytes, of the payload field (section 6.6 BitVoicer Server Protocol).

REMARKS:

The constants defined in the BVSP library (section 7.2.1.2 Constants) can be used to test the value

passed to the first parameter (data type).

7.2.1.4 ModeChangedPtr Type

DESCRIPTION:

Defines a function pointer for the function that will handle the modeChanged event of the BVSP class.

SINTAX:

typedef void (*ModeChangedPtr)(void)

7.2.1.5 StreamReceivedPtr Type

DESCRIPTION:

Defines a function pointer for the function that will handle the streamReceived event of the BVSP

class.

SINTAX:

typedef void (*StreamReceivedPtr)(int)

PARAMETERS:

int: The number of samples available for reading.

7.2.2 BVSMic

The BVSMic library provides the necessary resources to record audio samples using the Arduino

ADC (analog-to-digital converter). These samples are stored in the class internal buffer so they can be

retrieved and sent to the speech recognition engines available on BitVoicer Server.

7.2.2.1 BVSMic Class

DESCRIPTION:

Provides a set of members and functions that enables recording of audio samples using the Arduino

analog pins.


http://en.wikipedia.org/wiki/Analog-to-digital_converter



CONSTRUCTORS:

public BVSMic(): Initializes a new instance of the BVSMic class.

MEMBERS:

int available: Gets the number of samples available for reading in the internal buffer.

boolean isRecording: Gets a value that indicates whether the BVSMic class is currently capturing audio.

FUNCTIONS:

void begin(): Defines the settings of the Arduino timer to achieve 8000 samples per second.

Remarks:

The begin function must be called before any other function of the BVSMic class.

byte getAnalogPin(): Returns the number of the analog pin being used to capture audio. This number is

defined through the setAudioInput function.

Return value:

byte: The number of the analog pin being used to capture audio.

unsigned long getEOCInterrupt(): Returns a value that indicates which end of conversion interrupt

(ADC_IER register) is being used by the BVSMic class. This function is only supported in the Arduino

DUE.

Return value:

unsigned long: An unsigned long (32-bit integer) with one of its bits between position 0 and 15 set

to 1.

int read(byte *buffer, int bufferSize): Reads all audio samples available in the internal buffer and

writes them into the specified byte array.




Parameters:

byte *buffer: The byte array into which the audio samples will be written starting at position zero.

int bufferSize: The size of the array passed to the buffer parameter.

Return value:

int: The number of samples effectively read. If the internal buffer is empty, it returns zero.

int read(byte *buffer, int bufferSize, int offset, int count): Reads the specified number of

samples from the internal buffer and writes them into a byte array.

Parameters:

byte *buffer: The byte array into which the audio samples will be written.

int bufferSize: The size of the array passed to the buffer parameter.

int offset: The offset in buffer to begin writing samples.

int count: The number of samples to be read.

Return value:

int: The number of samples effectively read. If the internal buffer is empty, it returns zero.

void resetBuffer(): Discards all audio samples stored in the internal buffer and resets the writing and

reading positions to their initial values.

void setAudioInput(byte pin, byte analogReference): Sets which analog pin will be used to capture

audio samples and which reference voltage will be used by the ADC.

Parameters:

byte pin: The number of the analog pin at which readings will be performed in order to capture

audio samples.

byte analogReference: One of the constants used in the analogReference function of the Arduino

platform.

Remarks:

The Arduino DUE board supports only the DEFAULT reference voltage (3.3V in this case). Trying to

use other reference voltages with this board has no practical effect.

Do not use anything less than 0V or more than 5V for external reference voltage on the AREF

pin. If you are using an external reference on the AREF pin, you must set the analog

reference to EXTERNAL before starting the audio recording.

void startRecording(): Starts capturing and recording audio.


http://www.arduino.cc/en/Reference/AnalogReference



void stopRecording(): Stops capturing and recording audio.

void write(byte sample): Writes one audio sample into the internal buffer.

Parameters:

byte sample: The audio sample to be written.

REMARKS:

The BVSMic class uses an internal buffer to store audio samples. The size of this buffer is

determined by the BVSM_BUFFER_SIZE constant defined in the BVSMic.h file and its default value is 128

(bytes). A buffer this size is able to store 16 milliseconds of audio at 8000 samples per second. If the internal

buffer is not read before it gets full, new audio samples are simply discarded. If the interval between readings

is greater than 16 milliseconds, the size of the buffer can be increased through the BVSM_BUFFER_SIZE

constant using the following equation:

( interval between readings in milliseconds / 1000 ) * 8000 = size of the buffer in bytes

The BVSMic class uses the following timers to generate interrupts:

Arduino DUE: timer counter 1 channel 2 (TC5).

Arduino Micro, Leonardo, Yún, LyliPad USB and other boards based on the ATmega32u4

microcontroller: timer counter 3 (timer3).

Arduino UNO, Mega and other boards based on ATmega microcontrollers: timer counter 2

(timer2).

The tone function and PWM outputs also use timers. Make sure your code does not use the same

timers used by the BVSMic class.

7.2.2.2 Constants

#define BVSM_BUFFER_SIZE 128

7.2.3 BVSSpeaker

The BVSSpeaker library provides the necessary resources to reproduce audio streams sent from

BitVoicer Server (section 3.1.3.4 Synthesized Speech). To reproduce audio, the Arduino board must have an

integrated DAC (digital-to-analog converter) or make use of an external one. Currently, this library is only

supported by the Arduino DUE (the only board with integrated DACs).

7.2.3.1 BVSSpeaker Class

DESCRIPTION:

Reproduces synthesized speech using the digital-to-analog converter of the Arduino DUE.


http://en.wikipedia.org/wiki/Microcontroller#Interrupts

http://www.arduino.cc/en/Reference/Tone

http://en.wikipedia.org/wiki/Digital-to-analog_converter



CONSTRUCTORS:

public BVSSpeaker(): Initializes a new instance of the BVSSpeaker class.

METHODS:

void begin(DACClass &dac): Prepares the BVSSpeaker class for audio reproduction.

Parameters:

DACClass &dac: A DACClass instance. The DAC library (available in the same folder of the

BVSSpeaker library) creates one DACClass instance called DAC that can be used in this parameter

(refer to the Implementing Speech Recognition and Synthesis example).

Remarks:

The begin function must be called before any other function of the BVSSpeaker class.

int enqueue(byte *data, int count): Queues the specified number of audio samples for reproduction.

Parameters:

byte *data: The byte array that contains the audio samples to be reproduced.

int count: The number of samples to be reproduced starting at position zero.

Return value:

int: The number of samples effectively queued for reproduction.

Remarks:

The enqueue function can be called at any moment to queue audio samples, even while the

BVSSpeaker class is already reproducing audio.

In case the internal buffer does not have enough free memory to store all samples being queued,

only those that can be stored will be queued.

void finishPlaying(): Signals the BVSSpeaker class that it must reproduce the audio samples in the

internal buffer and then stop the reproduction.

int getQueueCount(): Returns the number of samples in the internal buffer that are waiting for

reproduction. This function can be used to know the level of usage of the buffer.

Return value:

int: The number of samples in the internal buffer waiting for reproduction.




boolean isPlaying(): Returns a value that indicates whether the BVSSpeaker class is currently

reproducing audio.

Return value:

boolean: True if it is reproducing audio. Otherwise, false.

void play(): Verifies if there are audio samples available in the internal buffer and reproduces them.

Remarks:

In case the finishPlaying function has been called, the play function will keep reproducing audio

until all audio samples present in the internal buffer have been played.

REMARKS:

The BVSSpeaker class uses three internal buffers to reproduce audio. The largest of these buffers

queues the audio samples to be reproduced. The size of this buffer is determined by the

BVSSPEAKER_QUEUE_SIZE constant defined in the BVSSpeaker.h file and its default value is 8192 (bytes). A

buffer this size enables the BVSSpeaker class to store about one second of audio in the format defined by

the BitVoicer Server Protocol (section 6.3.2 Stream Mode). If the transfer rate between the server and the

device is greater than 8000 bytes per second and the audio to be reproduced is longer than one second, the

internal buffer may overflow and audio samples may be lost. To avoid this situation, increase the size of the

buffer or change the transfer rate in the device properties (section 4.1.2.2 Communication). The other two

buffers are loaded alternately by the BVSSpeaker class and accessed by the Arduino DAC using DMA

(Direct Memory Access). The size of these buffers are determined by the BVSSPEAKER_DAC_BUFFER_SIZE

constant defined in the BVSSpeaker.h file and its default value is 512 (bytes).

The BVSSpeaker class uses the DAC0 of the Arduino DUE to convert digital audio streams (8-bit

PCM at 8000 samples per second) into analog signals.

7.2.3.2 Constants

#define BVSSPEAKER_QUEUE_SIZE 8192

#define BVSSPEAKER_DAC_BUFFER_SIZE 512


http://en.wikipedia.org/wiki/Direct_memory_access



8 Examples

The following sections contain practical implementation examples of the main features available in

BitVoicer Server.

The examples 8.1, 8.2, 8.3, and 8.4 were developed and tested using the Arduino platform (IDE

version 1.6.3). To compile these examples, you also need to install the BitVoicer Server Arduino Libraries.

The example 8.5 does not require the use of external capturing devices (only the server’s audio

adapter).

8.1 Getting the Server Status

This example demonstrates how to retrieve status information from the server and display it using

LEDs. The BVSP status frames (section 6.6.1.5.1 Status Payload) contain three status indications: if the

server is running; if there is a speech recognition engine (SRE) assigned to the device; and if the Data

Forwarding Module is running. In this example an output device is used (section 4.1.2 Devices). Therefore,

no SRE will be assigned to the device and only two of the three LEDs will light up.

8.1.1 Required Material

Server running BitVoicer Server 1.0

Arduino board (any model)

USB cable for the Arduino

3 LEDs

3 resistors (if you do not have the LED specifications, use 200 ohms resistors at least)

Breadboard

Jumper cables for the breadboard

8.1.2 Step-by-Step

1) Mount the three LEDs and resistors on the breadboard and connect them to the Arduino as shown in

the picture below:


http://www.arduino.cc/

http://en.wikipedia.org/wiki/Breadboard



2) Open the Arduino IDE and load the BVSStatus example sketch (File Examples BVSP

Examples BVSPStatus). The sketch code is shown in the picture below:

#include <BVSP.h> // Defines the Arduino pins that will be used to control // the LEDs #define BVS_RUNNING 3 #define BVS_SRE 5 #define BVS_DATA_FWD 4 // Defines the constants that will be passed as parameters to // the BVSP.begin function const unsigned long STATUS_REQUEST_INTERVAL = 2000; const unsigned long STATUS_REQUEST_TIMEOUT = 1000; // Initializes a new global instance of the BVSP class BVSP bvsp = BVSP(); void setup() { // Starts serial communication at 115200 bps Serial.begin(115200); // Sets the Arduino pin modes pinMode(BVS_RUNNING, OUTPUT); pinMode(BVS_SRE, OUTPUT); pinMode(BVS_DATA_FWD, OUTPUT);




// Sets the Arduino serial port that will be used for // communication, how long it will take before a status request // times out and how often status requests should be sent to // BitVoicer Server bvsp.begin(Serial, STATUS_REQUEST_TIMEOUT, STATUS_REQUEST_INTERVAL); } void loop() { // Checks if the status request interval has elapsed and if it // has, sends a status request to BitVoicer Server bvsp.keepAlive(); // Checkes if there is data available at the serial port buffer // and processes its content according to the specifications // of the BitVoicer Server Protocol bvsp.receive(); // Gets the respective status from the BVSP class and sets // the LEDs on or off digitalWrite(BVS_RUNNING, bvsp.isBVSRunning()); digitalWrite(BVS_DATA_FWD, bvsp.isDataFwdRunning()); digitalWrite(BVS_SRE, bvsp.isSREAvailable()); }

3) Connect the Arduino to the PC and upload the code to the Arduino.

4) Open the BitVoicer Server Manager and create the location (section 4.1.1 Locations) where the

device will be installed. If the location already exists, skip to the next step.

5) Create an Output device, specify its serial number and location, set up its communication interface

(section 4.1.2 Devices) and save the device.

A few seconds after the device is saved, the LEDs connected to pins 3 and 4 will light up. The LED

connected to pin 5 will remain off because SREs are not assigned to output devices (section 3.1.3.1 Speech

Recognition Engine Assignment). While the sketch is running, the TX and RX LEDs of the Arduino will blink

in sequence every two seconds. This blinking means that the Arduino is performing status requests and

receiving responses from the server.

8.2 Implementing Speech Recognition

This example demonstrates how to implement speech recognition using a microphone connected to

one of the Arduino analog pins. In this example, the same approach for getting the server status

demonstrated in the previews section is used. However, one LED is added to provide a visual clue that the

activation-word-activated period has begun or ended (section 3.1.3.2 Validation Filters).



Input device license (section 2.4 Licensing)


SparkFun Electret Microphone Breakout (BOB-09964)


4 LEDs


Breadboard



http://www.sparkfun.com/products/9964




8.2.2 Step-by-Step

1) Mount the four LEDs and resistors on the breadboard and connect the microphone and the

breadboard to the Arduino as shown in the picture below:

2) Open the Arduino IDE and load the SpeechRecognition example sketch (File Examples

BVSMic Examples SpeechRecognition). The sketch code is shown in the picture below:

#include <BVSP.h> #include <BVSMic.h> // Defines the Arduino pins that will be used to control // the LEDs and capture audio #define BVS_RUNNING 3 #define BVS_SRE 5 #define BVS_DATA_FWD 4 #define BVS_ACT_PERIOD 6 #define BVSM_AUDIO_INPUT 0 // Defines the constants that will be passed as parameters to // the BVSP.begin function const unsigned long STATUS_REQUEST_INTERVAL = 2000; const unsigned long STATUS_REQUEST_TIMEOUT = 1000; // Defines the size of the audio buffer const int AUDIO_BUFFER_SIZE = 64;




// Defines the size of the string buffer const int STRING_BUFFER_SIZE = 64; // Initializes a new global instance of the BVSP class BVSP bvsp = BVSP(); // Initializes a new global instance of the BVSMic class BVSMic bvsm = BVSMic(); // Creates a buffer that will be used to read recorded samples // from the BVSMic class byte audioBuffer[AUDIO_BUFFER_SIZE]; // Creates a string buffer (char array) to retrieve strings // sent from BitVoicer Server char stringBuffer[STRING_BUFFER_SIZE]; void setup() { // Starts serial communication at 115200 bps Serial.begin(115200); // Sets the Arduino pin modes pinMode(BVS_RUNNING, OUTPUT); pinMode(BVS_SRE, OUTPUT); pinMode(BVS_DATA_FWD, OUTPUT); pinMode(BVS_ACT_PERIOD, OUTPUT); // Sets the Arduino serial port that will be used for // communication, how long it will take before a status request // times out and how often status requests should be sent to // BitVoicer Server bvsp.begin(Serial, STATUS_REQUEST_TIMEOUT, STATUS_REQUEST_INTERVAL); // Defines the function that will handle the frameReceived // event bvsp.frameReceived = BVSP_frameReceived; // Prepares the BVSMic class timer bvsm.begin(); } void loop() { // Checks if the status request interval has elapsed and if it // has, sends a status request to BitVoicer Server bvsp.keepAlive(); // Checks if there is data available at the serial port buffer // and processes its content according to the specifications // of the BitVoicer Server Protocol bvsp.receive(); // Gets the respective status from the BVSP class and sets // the LEDs on or off digitalWrite(BVS_RUNNING, bvsp.isBVSRunning()); digitalWrite(BVS_DATA_FWD, bvsp.isDataFwdRunning()); // Checks if there is a SRE assigned to the Arduino




if (bvsp.isSREAvailable()) { // Turns on the SRE available LED digitalWrite(BVS_SRE, HIGH); // If the BVSMic class is not recording, sets up the audio // input and starts recording if (!bvsm.isRecording) { bvsm.setAudioInput(BVSM_AUDIO_INPUT, EXTERNAL); bvsm.startRecording(); } // Checks if the BVSMic class has available samples if (bvsm.available) { // Makes sure the inbound mode is STREAM_MODE before // transmitting the stream if (bvsp.inboundMode == FRAMED_MODE) bvsp.setInboundMode(STREAM_MODE); // Reads the audio samples from the BVSMic class int bytesRead = bvsm.read(audioBuffer, AUDIO_BUFFER_SIZE); // Sends the audio stream to BitVoicer Server bvsp.sendStream(audioBuffer, bytesRead); } } else { // There is no SRE available // Turns off the SRE and ACT_PERIOD LEDs digitalWrite(BVS_SRE, LOW); digitalWrite(BVS_ACT_PERIOD, LOW); // If the BVSMic class is recording, stops it if (bvsm.isRecording) bvsm.stopRecording(); } } // Handles the frameReceived event void BVSP_frameReceived(byte dataType, int payloadSize) { // Performs the appropriate actions based on the frame // data type switch (dataType) { case DATA_TYPE_BYTE: // Turns the ACT_PERIOD LED on or off depending on the // the value of the received byte digitalWrite(BVS_ACT_PERIOD, bvsp.getReceivedByte()); break; case DATA_TYPE_STRING: // Performs further actions only if characters are retrieved // from the frame if (bvsp.getReceivedString(stringBuffer, STRING_BUFFER_SIZE) != 0); { // If the received string is equal to blink, turns // all LEDs off and on 3 times if (strcmp(stringBuffer, "blink") == 0)




{ AllLEDsOff(); delay(100); AllLEDsOn(); delay(100); AllLEDsOff(); delay(100); AllLEDsOn(); delay(100); AllLEDsOff(); delay(100); AllLEDsOn(); } } break; } } // Turns all LEDs on void AllLEDsOn() { digitalWrite(BVS_RUNNING, HIGH); digitalWrite(BVS_SRE, HIGH); digitalWrite(BVS_DATA_FWD, HIGH); digitalWrite(BVS_ACT_PERIOD, HIGH); } // Turns all LEDs off void AllLEDsOff() { digitalWrite(BVS_RUNNING, LOW); digitalWrite(BVS_SRE, LOW); digitalWrite(BVS_DATA_FWD, LOW); digitalWrite(BVS_ACT_PERIOD, LOW); }




5) Create a Mixed device, specify its serial number and location, and set up its communication interface

(section 4.1.2 Devices).

6) In the Cues tab, enable the cues for start and end of activated period.

7) Set up the cues below in the Cues tab and save the device:

a. Set the Target Device to the device itself.




8) Create a Voice Schema (section 4.1.4 Voice Schemas) and set its activation word to “Arduino”.

9) In the Input Devices tab, set the recently created device as input device.

10) In the Sentences tab, add the text “blink all leds” to the sentence.

11) In the Anagrams/Commands tab, add the command below to the recently created Anagram:

12) Save the Voice Schema.

A few seconds after the device is saved, the LEDs connected to pins 3, 4 and 5 will light up. The

LED connected to pin 6 will remain off until the activation word (“Arduino”) is recognized. At the end of the

activation-word-activated period (section 4.1.2.1 General), the LED connected to pin 6 will turn off.

The command created in step 11 establishes that the “blink” string must be sent to the target device

when the “blink all leds” Anagram is recognized. The sketch running on the Arduino will identify this string

and blink all LEDs three times at 100 millisecond intervals.




You can monitor the status of the SRE assigned to the device and the recognitions performed by it

through the Server Monitor tool.

8.3 Implementing Speech Recognition and Synthesis

This example uses an Arduino DUE to perform speech recognition and synthesis through the same

device. Currently, the Arduino DUE is the only Arduino board that has integrated DACs (digital-to-analog

converter) capable of converting digital audio streams into analogic signals. Other Arduino boards require an

external DAC. The BVSSpeaker library used in this example is only supported by the Arduino DUE.

This example uses a WiFi network module to demonstrate how to access the BitVoicer Server

services through a TCP/IP communication interface. This module can also be used on all other examples.




Arduino DUE board

SparkFun XBee Shield (WRL-12847)

WiFi module RN171VX

Local WiFi network with WPA authentication

SparkFun Electret Microphone Breakout (BOB-09964)

SparkFun Mono Audio Amp Breakout (BOB-11044)

8-Ohm speaker


4 LEDs


Breadboard


8.3.2 Step-by-Step

The first stage of this example consists in setting up the WiFi module to access the local network and

communicate with the Arduino and BitVoicer Server. To do that, follow the steps described below:

1) Open the Arduino IDE and create a new sketch using the code below:

void setup() { Serial.begin(9600); pinMode(13, OUTPUT); delay(5000); Serial.print("$$$"); delay(1000); Serial.println("set wlan auth 4"); delay(1000); Serial.println("set wlan phrase XXXXXX"); delay(1000); Serial.println("set wlan ssid XXXXXX"); delay(1000); Serial.println("set wlan channel 0"); delay(1000); Serial.println("set wlan join 1"); delay(1000); Serial.println("set wlan tx 0"); delay(1000); Serial.println("set ip dhcp 0");





http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en560635






delay(1000); Serial.println("set ip address 192.168.0.200"); delay(1000); Serial.println("set comm remote 0"); delay(1000); Serial.println("set comm close 0"); delay(1000); Serial.println("set comm open 0"); delay(1000); Serial.println("set comm size 500"); delay(1000); Serial.println("set comm time 50"); delay(1000); Serial.println("set uart baud 115200"); delay(1000); Serial.println("set uart flow 0"); delay(1000); Serial.println("save"); delay(1000); Serial.println("exit"); delay(1000); digitalWrite(13, LOW); } void loop() { }

2) Alter the “set wlan phrase” command by replacing the “XXXXXX” section with the password of your

WiFi network.

3) Alter the “set wlan ssid” command by replacing the “XXXXXX” section with the name of your WiFi

network.

4) Set the static IP address of the WiFi module in the “set ip address” command.


6) Disconnect the Arduino from the PC.

7) Attach the WiFi module to the SparkFun XBee shield.

8) Make sure the SPDT switch on the shield is in the “UART” position.

9) Attach the shield to the Arduino DUE and reconnect the Arduino to the PC.

10) Wait for about thirty seconds for the setup process to finish. During this process, the DIN e DOUT

LEDs on the shield will blink when data is exchanged between the Arduino and the WiFi module.

11) After the setup process is finished, disconnect the Arduino from the PC and position the SPDT

switch in the “DLINE” position. Reconnect the Arduino to the PC.

12) Wait for a few seconds and perform a ping test using the command prompt (Start All Programs

Accessories Command Prompt). Type “ping ” followed by the IP address assigned to the module

(e.g. “ping 192.168.0.200). If there is no response from the module, redo the previous steps or check

the module documentation.

At this point, the WiFi module is ready to communicate with BitVoicer Server and the Arduino. The

following steps describe how to connect the remaining components to the Arduino, implement the BVSP,

BVSMic and BVSSpeaker classes and prepare the BitVoicer Server Solution to serve the device:




1) Mount the four LEDs and resistors on the breadboard and connect the microphone, the amplifier and

the breadboard to the Arduino as shown in the picture below:

2) Open the Arduino IDE and load the FullSpeech example sketch (File Examples BVSSpeaker

Examples FullSpeech). The sketch code is shown in the picture below:

#include <DAC.h> #include <BVSP.h> #include <BVSMic.h> #include <BVSSpeaker.h> // Defines the Arduino pins that will be used to control // LEDs and capture audio #define BVS_RUNNING 3 #define BVS_SRE 5 #define BVS_DATA_FWD 4 #define BVS_ACT_PERIOD 6 #define BVSM_AUDIO_INPUT 0 // Defines the constants that will be passed as parameters to // the BVSP.begin function const unsigned long STATUS_REQUEST_INTERVAL = 4000; const unsigned long STATUS_REQUEST_TIMEOUT = 2000; // Defines the size of the mic buffer const int MIC_BUFFER_SIZE = 64; // Defines the size of the speaker buffer const int SPEAKER_BUFFER_SIZE = 128;




// Initializes a new global instance of the BVSP class BVSP bvsp = BVSP(); // Initializes a new global instance of the BVSMic class BVSMic bvsm = BVSMic(); // Initializes a new global instance of the BVSSpeaker class BVSSpeaker bvss = BVSSpeaker(); // Creates a buffer that will be used to read recorded samples // from the BVSMic class byte micBuffer[MIC_BUFFER_SIZE]; // Creates a buffer that will be used to write audio samples // into the BVSSpeaker class byte speakerBuffer[SPEAKER_BUFFER_SIZE]; // Creates a global variable that indicates whether the // Arduino is connected to BitVoicer Server boolean connected = false; void setup() { // Starts serial communication at 115200 bps Serial.begin(115200); // Sets the Arduino pin modes and turns all LEDs off pinMode(BVS_RUNNING, OUTPUT); pinMode(BVS_SRE, OUTPUT); pinMode(BVS_DATA_FWD, OUTPUT); pinMode(BVS_ACT_PERIOD, OUTPUT); AllLEDsOff(); // Sets the Arduino serial port that will be used for // communication, how long it will take before a status request // times out and how often status requests should be sent to // BitVoicer Server bvsp.begin(Serial, STATUS_REQUEST_TIMEOUT, STATUS_REQUEST_INTERVAL); // Sets the function that will handle the frameReceived // event bvsp.frameReceived = BVSP_frameReceived; // Sets the function that will handle the modeChanged // event bvsp.modeChanged = BVSP_modeChanged; // Sets the function that will handle the streamReceived // event bvsp.streamReceived = BVSP_streamReceived; // Prepares the BVSMic class timer bvsm.begin(); // Sets the DAC that will be used by the BVSSpeaker class bvss.begin(DAC); } void loop() {




// If it is not connected to the server, opens a TCP/IP // connection, sets connected to true and resets the BVSP // class if (!connected) { Connect(Serial); connected = true; bvsp.reset(); } // Checks if the status request interval has elapsed and if it // has, sends a status request to BitVoicer Server bvsp.keepAlive(); // Checks if there is data available at the serial port buffer // and processes its content according to the specifications // of the BitVoicer Server Protocol bvsp.receive(); // Gets the respective status from the BVSP class and sets // the LEDs on or off digitalWrite(BVS_RUNNING, bvsp.isBVSRunning()); digitalWrite(BVS_DATA_FWD, bvsp.isDataFwdRunning()); // Checks if there is a SRE assigned to the Arduino if (bvsp.isSREAvailable()) { // Turns on the SRE available LED digitalWrite(BVS_SRE, HIGH); // If the BVSMic class is not recording, sets up the audio // input and starts recording if (!bvsm.isRecording) { bvsm.setAudioInput(BVSM_AUDIO_INPUT, DEFAULT); bvsm.startRecording(); } // Checks if the BVSMic class has available samples if (bvsm.available) { // Makes sure the inbound mode is STREAM_MODE before // transmitting the stream if (bvsp.inboundMode == FRAMED_MODE) bvsp.setInboundMode(STREAM_MODE); // Reads the audio samples from the BVSMic class int bytesRead = bvsm.read(micBuffer, MIC_BUFFER_SIZE); // Sends the audio stream to BitVoicer Server bvsp.sendStream(micBuffer, bytesRead); } } else { // There is no SRE available // Turns off the SRE and ACT_PERIOD LEDs digitalWrite(BVS_SRE, LOW); digitalWrite(BVS_ACT_PERIOD, LOW); // If the BVSMic class is recording, stops it




if (bvsm.isRecording) bvsm.stopRecording(); } // Plays the audio samples available in the internal buffer bvss.play(); // If the status has timed out, the connection is considered // lost if (bvsp.hasStatusTimedOut()) { // If the BVSMic is recording, stops it if (bvsm.isRecording) bvsm.stopRecording(); // Closes the TCP/IP connection Disconnect(Serial); AllLEDsOff(); connected = false; } } // Handles the modeChanged event void BVSP_modeChanged() { // If the outboundMode (Server --> Device) has turned to // FRAMED_MODE, no audio stream is supposed to be received. // Tells the BVSSpeaker class to finish playing when its // internal buffer become empty. if (bvsp.outboundMode == FRAMED_MODE) bvss.finishPlaying(); } // Handles the streamReceived event void BVSP_streamReceived(int size) { // Gets the received stream from the BVSP class int bytesRead = bvsp.getReceivedStream(speakerBuffer, SPEAKER_BUFFER_SIZE); // Enqueues the received stream for reproduction bvss.enqueue(speakerBuffer, bytesRead); } // Handles the frameReceived event void BVSP_frameReceived(byte dataType, int payloadSize) { // Performs the appropriate actions based on the frame // data type switch (dataType) { case DATA_TYPE_BYTE: // Turns the ACT_PERIOD LED on or off based on the // the value of the received byte digitalWrite(BVS_ACT_PERIOD, bvsp.getReceivedByte()); break; } } // Opens a TCP/IP connection with the BitVoicer Server




void Connect(HardwareSerial &serialPort) { serialPort.print("$$$"); delay(500); // Use the IP address of the server and the TCP port set // in the server properties serialPort.println("open 192.168.0.117 4194"); delay(1000); serialPort.println("exit"); delay(500); } // Closes the TCP/IP connection with the BitVoicer Server void Disconnect(HardwareSerial &serialPort) { serialPort.print("$$$"); delay(500); serialPort.println("close"); delay(1000); serialPort.println("exit"); delay(500); } // Turns all LEDs off void AllLEDsOff() { digitalWrite(BVS_RUNNING, LOW); digitalWrite(BVS_SRE, LOW); digitalWrite(BVS_DATA_FWD, LOW); digitalWrite(BVS_ACT_PERIOD, LOW); }

3) Alter the server IP address in the Connect function of the sketch above using the server IP address.


5) Position the SPDT switch in the “UART” position.



7) Create a Mixed device, specify its serial number and location, and set up its communication interface

using the IP address of to the WiFi module (section 4.1.2 Devices).

8) In the Cues tab, enable the cues for start and end of activated period.

9) Set up the cues below in the Cues tab and save the device:

a. Set the Target Device to the device itself.




10) Create a Voice Schema (section 4.1.4 Voice Schemas) and set its activation word to “Arduino”.

11) In the Input Devices tab, set the recently created device as input device.

12) In the Sentences tab, add the text “are you there” to the sentence.

13) In the Anagrams/Commands tab, add the command below to the recently created Anagram:


A few seconds after the device is saved, the LEDs connected to pins 3, 4 and 5 will light up. The

LED connected to pin 6 will remain off until the activation word (“Arduino”) is recognized. At the end of the

activation-word-activated period (section 4.1.2.1 General), the LED connected to pin 6 will turn back off.

The command created in step 12 establishes that a synthesized audio stream must be sent to the

target device when the “are you there” Anagram is recognized. The sketch running on the Arduino will

receive and reproduce this stream using the Arduino internal DAC.




You can monitor the status of the SRE assigned to the device and the recognitions performed by it

through the Server Monitor tool.

Due to the peak current draws caused by the WiFi module, the use of an external power source (7 to

12 volts) for the Arduino DUE is recommended.

8.4 Using the Data Forwarding Module

This example demonstrates how to implement the features available in the Data Forwarding Module.

Data exchange between external applications and BitVoicer Server is not covered in this example (for

information on this subject, refer to section 7.1.1 BitSophia.BitVoicerServer.Integration).

The Server Monitor tool (more specifically the Data Forwarding tab) will be used in this example to

send data to a client device that will retransmit this data back to the server monitor (round trip). In other

words, data will be transmitted through the following path: server monitor BitVoicer Server client device

BitVoicer Server server monitor.





8.4.2 Step-by-Step

1) Open the Arduino IDE and load the DataForwarding example sketch (File Examples BVSP

Examples DataForwarding). The sketch code is shown in the picture below:

#include <BVSP.h> // Defines the constants that will be passed as parameters to // the BVSP.begin function const unsigned long STATUS_REQUEST_INTERVAL = 2000; const unsigned long STATUS_REQUEST_TIMEOUT = 1000; // Initializes a new global instance of the BVSP class BVSP bvsp = BVSP(); void setup() { // Starts serial communication at 115200 bps Serial.begin(115200); // Sets the Arduino serial port that will be used for // communication, how long it will take before a status request // times out and how often status requests should be sent to // BitVoicer Server bvsp.begin(Serial, STATUS_REQUEST_TIMEOUT, STATUS_REQUEST_INTERVAL); // Sets the function that will handle the frameReceived // event bvsp.frameReceived = BVSP_frameReceived; } void loop() { // Checkes if there is data available at the serial port buffer // and processes its content according to the specifications




// of the BitVoicer Server Protocol bvsp.receive(); } // Handles the frameReceived event void BVSP_frameReceived(byte dataType, int payloadSize) { int bytesRead = 0; // Performs the appropriate actions based on the frame // data type switch (dataType) { case DATA_TYPE_BYTE: // Gets the received byte and sends it back to // BitVoicer Server bvsp.send(bvsp.getReceivedByte()); break; case DATA_TYPE_INT16: // Gets the received int16 and sends it back to // BitVoicer Server bvsp.send(bvsp.getReceivedInt16()); break; case DATA_TYPE_INT32: // Gets the received int32 and sends it back to // BitVoicer Server bvsp.send(bvsp.getReceivedInt32()); break; case DATA_TYPE_BINARY: byte byteBuffer[64]; // Retrieves the binary data from the frame bytesRead = bvsp.getReceivedBytes(byteBuffer, 64); // Sends the binary data back to BitVoicer Server bvsp.send(byteBuffer, 0, bytesRead); break; case DATA_TYPE_STRING: char charBuffer[64]; // Retrieves the string from the frame bvsp.getReceivedString(charBuffer, 64); // Sends the string back to BitVoicer Server bvsp.send(charBuffer); break; } }




4) Create an Output device, specify its serial number and location, set up its communication interface

(section 4.1.2 Devices) and save the device.




5) Open the Server Monitor tool and click on the Data Forwarding tab.

6) Select the device created in step 4 from the listbox and click on Bind.

7) Select the data type in the Send area, type the data in the textbox right below it and click on Send.

In this example, data sent from the Send area should be displayed in the Received area in the same

order they are sent. When data is displayed in the Received area, it has been transmitted through the whole

forwarding path: server monitor BitVoicer Server client device BitVoicer Server server monitor.

Right after the Send button is clicked, the RX and TX LEDs of the Arduino should blink quickly in

sequence. This means that the Arduino is receiving data and sending it back to the server.

8.5 Using the Server Audio Adapter

This example uses only the server audio adapter to perform speech recognition and synthesis.

However, BitVoicer Server supports any combination of device and adapter to perform both operations:

device/device; device/adapter; adapter/device; and adapter/adapter.

The Voice Schema (section 4.1.4 Voice Schemas) used in this example employs a question/answer

pattern in which a small directed dialog is established. These dialogs can lead to the execution of specific

commands and increase the sense of interactivity.




Microphone connected to the server audio adapter

Speaker connected to the server audio adapter

8.5.2 Step-by-Step

1) Open the BitVoicer Server Manager and create the location (section 4.1.1 Locations) that will be

associated with the Input and Output devices. If the location already exists, skip to the next step.

2) Create a SystemSpeaker device, specify its location and save it.

3) Create a SystemMic device and specify its location.

4) Enable the Start of Activated Period cue located in the Cues tab.

5) Create the following cue in the Cues tab and save the device:

a. Set the Target Device to the recently created SystemSpeaker device.

b. The full file path used in the picture below is: C:\Windows\Media\notify.wav




6) Create a Voice Schema (section 4.1.4 Voice Schemas) and set its activation word to “Computer”.

7) In the Input Devices tab, set the SystemMic device as input device.

8) In the Sentences tab, add the following sentences:

a. “are you there”

b. “let me know when you are done”

9) In the Anagrams/Commands tab, add the command below to the “are you there” Anagram:





10) Add the command below to the “let me know when you are done” Anagram:



After the Voice Schema is saved, you can conduct the following dialog with BitVoicer Server:

User: "Computer”

BitVoicer Server: A notification sound will be played to indicate that the activation-word-activated

period has begun.

User: “Are you there”

BitVoicer Server: “No sir, I am doing the dishes”

User: “Let me know when you are done”

BitVoicer Server: “Of course sir”


BitSophia - BitVoicer Server 1.0 User’s ...23 Inactivity Timeout: .

Documents

Transcript of BitSophia - BitVoicer Server 1.0 User’s ...23 Inactivity Timeout: .