Northwestern University
Chapter 1
OBJECTIVE
The ultimate objective of this project is to develop the next generation Text to Speech software for regional Indian languages like Hindi and Bengali which is called Embedded Shruti. The keyword here is “next generation”. The desktop version of this software which was developed by MediaLab, IIT Kharagpur is called “Shruti”. This software is ported to Windows CE so that the software can be used on Embedded Devices like Handhelds, PDA, Pocket-PC and other devices which support Windows CE operating system. While porting software on Windows CE the key concern is to enhance the performance using the limited resources of Windows CE. Windows CE is an operating system with limited resources and a small Application Programming Interface compared to the Win32 operating system which has an extensive set of Application Programming Interface. There are several limitations on the embedded devices like limited main memory, slow processor and less disk space. These are the constraints that should be taken into account while porting any software for Windows CE platform. Several techniques are used to increase the performance of the software which will be explained in the thesis and the performance evaluation will show how the techniques have resulted in increase in efficiency of the software. This project is an important part of the MediaLab projects and it had extended the Text to Speech software to an evolving area of handheld computers.
Chapter 2
INTRODUCTION
In recent past the computing industry had seen a tremendous growth in the area of Handheld Systems. Handheld Systems also called as Personal Digital Assistants (PDAs) are gaining popularity. An important reason behind their increase in popularity is that they are mobile devices. People can carry the devices with themselves at any place and use them for their work. Another important reason is that the devices are relatively cheap compared to desktop computes or Laptops. This is because they have limited functionalities. The resources are limited. The disk space is less, processor speed is not very high and main memory is also very limited compared to the desktop computers or Laptops.
The most popular Personal Digital Assistants are the following:
1. Pocket-PC
2. Palmtop
There are two popular operating systems that were used in these Personal Digital Assistants. They are the following:
1. Windows CE (compact edition)
2. Palm OS (Palm operating system used for Palmtops)
Embedded Shruti is developed for Pocket-PC running Windows CE operating system. As the name suggests Windows CE or Windows Compact Edition is an operating system developed by Microsoft which is customized for Handheld Devices. It had a subset of Win32 Application Programming Interface and also had Microsoft Foundation Class support. Due to the MFC support it’s very easy for the programmers who are conversant with traditional windows programming to migrate to windows CE programming. There are some constraints which should be kept in mind while programming in Windows CE API but one who is familiar with Windows API can develop applications for Windows CE very fast.
With this brief introduction of underlying hardware (Pocket-PC) and the operating system (Windows CE) the rest of the chapter will introduce the technologies that were used in the design and implementation of Embedded Shruti.
2.1 Windows CE Overview
Microsoft® Windows® CE is an open, scalable, 32-bit operating system (OS) that is designed to meet the needs of a broad range of intelligent devices, from enterprise tools such as industrial controllers, communications hubs, and point-of-sale terminals to consumer products such as cameras, telephones, and home entertainment devices. A typical Windows CE-based embedded system is targeted for a specific use, often runs disconnected from other computers, and requires an operating system that has a small footprint and a built-in deterministic response to interrupts.
Windows CE offers the application developer the familiar environment of the Microsoft Win32® application programming interface (API), ActiveX controls, message queuing (MSMQ) and Component Object Model (COM) interfaces, Active Template Library (ATL), and the Microsoft Foundation Classes (MFC) Library. ActiveSync provides easy connectivity between the desktop and the embedded device, whether by serial connection, infrared port, or network cable. There is built-in support for multimedia (including DirectX), communications (TCP/IP, SNMP, TAPI, and more), and security. A variety of integrated applications, including Pocket Internet Explorer, Pocket Outlook, and Pocket Word expose objects that allow the developer to extend and customize the existing system, as well as extend the functionality of the application.
2.1.1 Important features of Windows CE 3.0
Windows CE 3.0 offers improved Windows compatibility, combined with hard real-time processing support. New kernel services, such as support for nested interrupts, better thread response, additional task priorities, and semaphores, let the operating system respond immediately to events and interrupts. These real-time features make Windows CE 3.0 ideally suited for industrial applications such as robotics, test and measurement devices, and programmable logic controllers.
With greater storage and file-handling capabilities, interprocess communications, and networking support, Windows CE 3.0 interoperates easily with desktop environments that are based on Microsoft Windows NT® and Microsoft Windows 2000, which makes it the optimal choice for an enterprise system that combines small mobile systems with high-performance desktops servers and workstations.
New hardware features for Windows CE 3.0 include:
• Support for on-chip debugging.
• The device I/O controls (IOCTL) function that allows a unique serial number on each device.
• Multiple execute-in-place (XIP) regions.
2.1.1.1 Kernel Services
Thread response times have been improved in Windows CE 3.0 by the tightening of the upper bounds on scheduling latencies for high-priority Interrupt Service Threads (IST). This improvement in thread response allows developers to know specifically when the thread transitions occur, and aids them in creating new embedded applications by increasing the capabilities of monitoring and controlling hardware in Windows CE.
• Shorter Interrupt Service Routine (ISR) latencies. Because the kernel uses the interrupt ID that is provided by the ISR to set the event that the IST is waiting on, a short ISR latency is essential for a real-time system.
• Support for nested interrupts. Support has been added for nested interrupts, which allows interrupts at higher priority levels to be serviced immediately, instead of potentially waiting for a lower-priority ISR to complete.
• Increased priority levels. Additional priority levels (a total of 256) allow users more flexibility in controlling the scheduling of embedded systems.
• Support for semaphores. In addition to the currently supported mutexes and events, Windows CE has been expanded to support semaphores.
• The ability to change the quantum of any thread in the system. This includes support for two APIs: CeSetThreadQuantum and CeGetThreadQuantum.
• Kernel-level security. A new security model restricts access to system APIs that a rogue application could call to damage the platform. An OEM can specify whether modules and processes can run or not run and specify those that are fully trusted on a particular platform. Two new APIs allow software developers to retrieve the assigned trust level of a module or a process.
2.1.1.2 Files, Databases, and Persistent Storage
Windows CE 3.0 supports larger data storage systems, and larger files within those systems.
• The size of the object store has been increased to 256 MB (from 16 MB in Windows CE version 2.1). Individual files now can be as large as 32 MB and a database volume can be as large as 256 MB.
• The number of objects that can be kept in the object store has been increased from 216 (65,536) to 222 (4,194,304). Because the allowable number of objects exceeds the number of available object identifiers, freed object identifiers will be reused for new objects, effective with version 3.0. However, an object identifier will not be reused for at least 16 object allocations.
• Support has been added for querying VERSIONINFO resources to obtain version and language-support information from files.
2.1.1.3 Interprocess Communications
Windows CE 3.0 provides interprocess communication support with COM and MSMQ.
• Two separate COM modules offer two different levels of COM support: a limited-feature, small-footprint module that provides interprocess calls and a free-threading mode, and a larger module that supports out-of-process calls, full-threading model support, and Distributed Common Object Model (DCOM). The DCOM module, with the exception of the security interfaces, is fully compatible with Windows NT version 4.0 Service Pack 3 (SP3).
• Enhanced MSMQ support in Windows CE 3.0 provides independent client support for messaging applications. MSMQ for Windows CE is compatible with Windows NT and Windows 2000 Message Queuing Services.
2.1.1.4 Communication Services
Communications enhancements to Windows CE include the following:
• Lightweight remote access server (RAS) support. RAS uses Telephony Application Program Interface (TAPI) to make the call, and then manages the data through Point-to-point protocol (PPP) or Serial Line Interface Protocol (SLIP).
• Windows 2000 Transport Control Protocol/Internet Protocol (TCP/IP) support.
• Network Driver Interface Specification (NDIS) WAN support.
2.1.1.5 Communications Security
Security enhancements for Windows CE 3.0 include:
• Microsoft Cryptography version 2.0 API (CAPI) subset. This is a set of encryption APIs that allow development of applications that will work securely over nonsecure networks, such as the Internet. The CAPI 2.0 subset will provide certificate management support.
• Microsoft Enhanced Cryptography Service (RSAENH), including 128-bit encryption algorithms.
• Cryptography Service Provider Development Kit.
• X.509 certificate authentication.
2.1.1.6 Connectivity Services
• Smart card PC/SC support. The Windows CE 3.0 smart-card subsystem conforms to the Interoperability Specification for ICCs and Personal Computer Systems, which makes it easy to port existing smart-card applications to Windows CE devices.
• Windows CE 3.0 ActiveSync version 3.1.
2.1.1.7 User-Interface Services
Enhancements to shell services in Windows CE include the following:
• Microsoft Windows CE Handheld PC (H/PC), Professional Edition shell, which includes the following applications:
• Pocket Internet Explorer
• Pocket Inbox
• Pocket Word
• Help system
• Finer granularity componentization of common controls.
• Ability to print mixed text and graphics.
• Controls and dialog boxes that are resolution independent.
• Ability for user to change the appearance of the user interface for notifications.
• DirectDraw driver for Graphics Device Interface (GDI).
2.1.1.8 Internet Services
The new embedded Web Server provides many of the features of Microsoft Internet Information Services (IIS), which have been optimized for the limited resources of an embedded device. Features include:
• Support for the HTTP/1.0 protocol, persistent connections, multiple connections, file downloading, directory browsing, and multiple virtual paths.
• A remote administration tool for configuration.
• Basic and NT LAN Manager (NTLM) authentication support.
• Internet Services Application Program Interface (ISAPI) extensions and filters.
• Dynamic pages, through a subset of Active Server Pages (ASP pages).
• For client-side Internet development, Windows CE 3.0 includes a subset of the WinInet API, to support browser-based applications and FTP services.
2.1.2 Using Platform Builder
The platform builder can be used to create customized embedded platforms. By default a number of embedded hardware platforms are available which includes embedded platforms for microprocessors like:
a) ARM processors.
b) MIPS processors.
c) SHX processors.
d) IntelX86 processors (Used for debugging the application on desktop environment).
Platform builder is essential for creating customized embedded platforms which are hardware specific and not compatible to the processors mentioned above.
Introduction to the platform builder will help to port the application to some customized embedded platforms in future. The steps to do the customized platform design are specified below:
Platform builder helps the programmer to create customized embedded platforms:
1. Using platform builder with the desktop based Windows CE emulator.
2. Using platform builder with a Windows CE PC based hardware development environment.
3. Creating and adding features to the platform thus made by the platform builder.
2.1.2.1 Designing Operating System elements
Using the platform builder one can do the following:
a) Create a boot loader.
b) Create a Board Support Package.
c) Create a custom shell.
d) Selecting a configuration for the platform.
Getting Started
To build a platform based on Windows CE operating system the following steps are to be done:
1. Create a platform using Windows CE configuration with a standard development board (SDB).
2. Customize the platform with additional project and catalog features
3. Build the Operating System image to a hardware platform (CEPC). Platform builder includes boot loaders and Board Support Packages for the CEPC and many other hardware development platforms.
4. After refining and debugging platform on hardware development platform, one can adapt it for custom target device.
5. Create a boot loader, OEM adaptation layer and board support package for the specific target device. OEM adaptation layer (OAL) is the layer between KERNEL and TARGET-PLATFORM FIRMWARE.
6. Rebuild the Operating System using new Board Support Package, download it into target device and debug platform.
7. When the platform is complete export a Software Development Kit for the platform. Application developers can import that software development kit into development tools like eMbedded Visual C++.
Platform Creation
Platform creation is done using new platform wizard in which the following steps are done:
a) Select a board support package for the device.
b) Choose and Operating System configuration and variant.
c) Select the features for the platform.
After initial settings have been chosen, the new platform wizard sets up the environment with files that support operating system configuration that was selected. The features included in the platform depend on the operating system configuration which was chosen. There are 13 basic configurations included with Platform Builder and all of them are available from new platform wizard.
After the pictorial view of the whole process, an example of building Operating System image for a Thin Client will be provided.
Sequence of tasks in process of creating Windows CE based platform with Platform Builder:
[pic]
2.1.2.2 Thin Client Example
Platform builder was used to generate Windows CE image for a HCL Win Bee 4000JS Thin Client which is having the following hardware details:
1. 266 MHz National Geode Processor.
2. On board VGA controller up to 4.0 MB shared VRAM.
3. 64 MB RAM upgradeable to 256 MB.
4. 16 MB flash memory.
Peripheral support:
1. 104 key PS/2 keyboard.
2. PS/2 and serial mouse support.
3. Audio : 16 bit stereo sound output
4. Microphone output
Communications:
1. TCP/IP with DHCP support.
2. 10/100 Mbps Ethernet Twisted pair (UTP RJ45) Interface.
3. Full PPP(Point to Point Protocol) support
Server Operating System compatibility/support:
1. Citrix Win-frame and other Citrix compatible Operating system.
2. Windows NT server 4.0,Terminal Server Edition and Windows 2000 server family with CITRIX
Optional Support:
1. Smart card reader
2. ISDN support
3. LCD Display
4. USB ports
5. ISA and PCI Expansion slots
For the hardware description of the Thin Client given above a Windows CE image had been made and the first step was to choose an appropriate configuration. Platform builder provides two different configurations for Thin Clients which are the following:
1. Windows Thin Client – Minimal version of Microsoft Windows CE that includes Core Operating System and features necessary to support Microsoft terminal services.
2. Windows Thin Client with browser- This configuration supports the features of Windows Thin Client along with a browser.
Windows Thin Client configuration provides the starting point for remote desktop terminals, including those features necessary to support terminal services client. This configuration provides functionality for Remote Desktop Terminals through support for Microsoft Terminal Services client. It also has SNMP and local browser capabilities along with the possibility to adding additional Windows CE Operating System features.
After the appropriate configuration is selected for the Thin Client hardware is selected the next step is to select one or more available board support packages. Platform Builder supports a number of Board Support Packages.
2.1.2.3 Board Support Package
A board support package is a software package that contains:
1. Boot Loader
2. OEM Adaptation Layer (OAL)
3. Device drivers for standard development board (SDB) or Hardware Reference Platform
BSP is the main part of Microsoft Windows CE based platforms and contains source files and binary files.
The OEM adaptation layer (OAL) that links to Kernel image and supports:
a) Initializing and managing the hardware.
b) Device drives.
c) Boot loader.
d) Set of configuration files.
Use of Boot Loader:
1. Used during development to download Operating System image.
2. Once created BSP can be reconfigured through environmental variables and .bib and .reg file can be modified to attain the reconfiguration.
Interaction Diagram:
[pic]
Microsoft Platform Builder provides sample BSPs for many SDBs that are readily available in industry. By using the integrated BSP support, one can quickly evaluate the new Operating System features in Microsoft Windows CE.
BSP developments:
1. Extensive infrastructure is provided for developing BSP for SDB made by the developer or hardware.
2. Offers support for developing drivers for the platform.
3. Focus on customizing, refining and developing additional Operating System features.
Platform Builder provides BSPs for ten SDBs that are readily available for purchase. At present Platform Builder supports 4 types of BSPs which are the following:
1. ARM BSPs
2. MIPS BSPs
3. SHX BSPs
4. x86 BSPs
There are several third party BSPs that are available. Windows CE supported Thin Clients are also available commercially [ref 1].
2.1.2.4 Creating an OEM Adaptation Layer (OAL)
An OEM adaptation layer is a layer of code that resides between the Microsoft Windows CE Kernel and the hardware of target device.
Physically OAL is linked with kernel libraries to create the kernel libraries to create the kernel executable files. It also facilitates communication between the Operating System and the target device. It includes code to handle the following:
1. Interrupts
2. Timers
3. Power Management
4. Bus abstraction
5. Generic I/O control codes (IOCTL)
Creating the OAL is one of the more complex tasks in the process of getting a Windows CE Operating System to run on a new hardware platform.
Easiest way to create an OAL:
1. Copy the OAL implementation from a working platform and then modify it to suit the specific requirements of the platform under consideration.
2. If a new OAL must be created from beginning (similar implementations are not there) then it’s more useful to approach the development process in stages.
Each stage adds a little more functionality than the previous one and provides a convenient separation point where new features can be fixed and validated.
Steps of creating a new OAL:
1. Preparing BSP files for building the kernel.
a) Put the necessary directories and files to build the OAL and kernel image in place.
b) config.bib will be created or modified in this step.
2. Creating a Base OAL
a) Initialize the platform at startup.
b) Enable the serial port for debugging.
c) Initialize the communication settings.
d) Goal is to provide basic system initialization code that will support further debugging and to ensure that basic initialization code is complete and consistent with target device.
3. Enhancing OAL functionalities:
a) Enhance the Interrupt Service Subroutines.
b) Manage clock and timers.
c) There are alternate debugging options for
1. Ethernet.
2. Enable power management.
3. Provide platform information for applications.
Goal:
a) Implement the remainder of platform support functions.
b) Ensure the fact that full Operating System boot is possible.
4. Completing an OAL: Implement any additional features that the developer want to add to it.
2.1.2.5 Creating a Boot loader
Boot loader is an integral part of Windows CE Operating System development process and in some cases part of the final product solution. Purpose of the boot loader is following:
1. Place the Operating System image into memory.
2. Jump to Operating system startup routine.
3. Boot loader can obtain the OS image in a number of different ways:
a) Cabled connection(such as Ethernet)
b) Through USB or serial port.
c) It can also load the Operating System from a local storage device such as compact flash, a hard disk or a disk-on-chip.
d) It may store the image in Random Access Memory or in a nonvolatile storage like
1. Flash
2. EEPROM
3. Storage device
Boot loader is typically used during the development process to save time. Rather than transferring the developmental image to the target device through a manual process such as flash programming, the boot loader allows the developers to quickly download the new development image to the target device.
In many final product solutions the boot loader is removed from the product and the Operating System image is stored on the device and bootstrapped by system-reset process.
But there are platforms that do not efficiently support this ability, such as X86 platforms or platforms that perform pre boot task.
Most common form of boot loader is one that downloads Operating System image over the Ethernet into a target device RAM and much documentation is available on that.
2.1.2.6 Device Driver Development
The device drivers are included in every Windows CE operating system image are responsible for direct communication to devices.
A device is a physical or logical entity that requires:
a) Control
b) Resource Management
c) Both (a) and (b) from Operating System
A device driver is a software module that manages the operation of a:
1. Device
2. Protocol
3. Service
A device driver also manages virtual or logical devices. A virtual device exposes a physical device interface, even though there is no physical device to manage it. A device driver for a virtual device is indistinguishable from a device driver for a physical device. Virtual means that there is no physical device to manage but a device like interface is being exposed.
File system drivers are example of virtual device drivers.
Typically one can characterize drivers by the device interface they expose. In the simplest case there is one interface exposed downward to hardware and one interface upwards to the applications.
Interface to Hardware ( Hardware interface or bus interface
Interface to Application ( Device interface or client interface
Application, other drivers or the device manager can manipulate the device interfaces. The provider of the interface determines how these modules manipulate the client interface.
Buses are responsible for loading the drivers for the devices on their buses. Bus enumeration is the process of examining the bus and then loading appropriate drivers. Root bus driver is a registry enumerator.
Different processes load different drivers. The following tables show the processes that load drivers and what drivers they load.
| Process | Drivers |
| Graphics, Windowing and Event |Battery drivers |
|Subsystem(GWES) |Display drivers |
| |Notification LED drivers |
| |Printer drivers |
| Device Manager |Audio drivers, Keyboard drivers, Mouse driver, Serial drivers, |
|(Device.exe) |PC card drivers, USB devices and any other driver that exposes |
| |the stream interface. |
| File System |File System |
|(Filesys.exe) |Drivers |
Device driver source code:
1. The device driver source code is separated into platform dependent code.
2. CPU support package (CSP) drivers.
3. Common drivers.
2.1.2.7 Creating a Board Support Package
Windows CE provides the basic infrastructure that allows one to rapidly and easily create BSPs. Different device driver libraries like Microprocessor-native libraries are shipped in Platform Builder.
Microprocessor Native Libraries:
The microprocessor native libraries consist of device drivers for high integration microprocessors and their native peripherals. For example Strong-Arm microprocessor and its companion chip integrated many peripherals on microprocessor such as LCD, serial port, USB etc.
A SDB that uses a specific microprocessor will use the same set of microprocessor native drivers.
2.1.2.8 Thin Client example revisited
In the Thin Client example discussed above a configuration was chosen after carefully studying the hardware characteristics of the Thin Client. Do the following steps after opening the Platform Builder:
1. From the file menu, choose new platform, and new platform wizard will appear.
2. Choose next and select one or more available BSPs.
3. On the BSP page choose next and in the platform configuration dialog box, enter a name for the platform.
4. Select a platform configuration from the available configuration area which in this case will be Windows Thin Client with browser for this particular example.
After these steps are completed platform creation is completed. After that the next step is to build the platform:
The OS image will be built based on the platform that has been configured. To build an Operating System image select retail or debug build configuration, modify the platform settings as needed, such as enabling kernel debugger, and then build the image.
After the platform is configured, the platform can be built using the platform builder integrated development environment (IDE).
Platform builder creates an Operating System image in four stages:
1. Sysgen phase.
2. Feature build phase.
3. Release copy phase.
Build system generates header files, links modules, copies the resulting modules to a release directory, and generates a binary image file.
Static library as well as code supplied by the developer or the third party vendors is combined into a binary file and that is downloaded onto the device.
Sysgen Phase: Each feature selected from catalog has a corresponding sysgen variable. If a feature is included in platform, IDE sets the corresponding sysgen variable during the sysgen phase of the build process.
Build system uses these variables to link the corresponding static libraries into modules.
The system also filters the system header files, creating headers that only contain prototypes for the functions exported by the developer’s platform. Import libraries for the system modules are also created during this phase.
Feature Build Phase: After sysgen phase, feature build phase is run. During this phase, all user features including platform builder project (.pbp) files, source files and makefile (.mak) files are compiled and built.
Release Copy Phase: Build system copies all the files needed to make an OS image to the release directory. The modules and files created during the sysgen phase are copied to the directory first, followed by the files created by the feature build phase.
Make Image Phase: The project specific files which includes
Project.bib
Project.dat
Project.db
Project.reg
are copied into Release directory.
Now information in BIBInfo tab of the platform setting dialog box is then added for each module or file. During this phase, the files in the release directory are combined in binary image file Nk.bin. If some modification is done, then the image should be made again.
Platform Downloading
After the platform is built, the OS image associated with the platform will be downloaded to a target device. The IDE gives a mechanism that allows downloading using a number of types of communication hardware, an OS image to target device.
To download an Os image to a target device, there should be connection from development workstation to target device.
Target menu in the IDE provides functionality that allows the developer to download an OS image to a target device. Before downloading configure a connection to the target device. To download using Ethernet, the development workstation and the target device must be on the same subnet. If the subnets will differ then the target device cannot be connected and debugging the OS image will not be possible.
Transfer the Operating System image thus made to the Thin Client at the startup. To make a connection to the device, go to target menu and configure remote connection. Choose services tab and from the active named box choose a connection. This completes the deployment of the operating system image to the Thin Client. This process is the general way to build Windows CE Operating System image for a given hardware platform. Many a time this whole process is not necessary since there are some hardware platforms like Pocket-PC for whom Windows CE image were already built and tested. Such hardware platforms come preloaded with Windows CE image and as mentioned above they export a software development kit which the developers can use to build software for Pocket-PC. Embedded Shruti is also developed using the Pocket-PC software development kit not by building the Windows CE image from the scratch. But every embedded software developer should have an idea of the whole design process so that the software can be ported to custom platforms if required in the future. The process was explained using the Thin Client example. The Thin Client example was the first work carried out by me in this project.
2.1.3 Using Standard SDK
When included in the platform under development, the standard software development kit (SDK) for Microsoft® Windows® CE provides a common subset of features that allow an application written to conform to the standard SDK to run on a display-based Windows CE platform. To maintain compatibility with the standard SDK, an application must function with only the features provided in the standard SDK. Using additional features will make the application incompatible with the standard SDK. To implement the standard SDK on a Windows CE platform, the standard SDK for a Windows CE feature must be added to a display-based platform. The standard SDK is not compatible with headless devices and is therefore limited to display-based platforms. When added to an operating system (OS) image, the standard SDK will automatically include any features associated with the standard SDK as well as their dependencies. It will also add a registry flag to the image that indicates that the standard SDK has been implemented on that image. This allows any application written for the standard SDK to verify that a particular Windows CE platform supports the standard SDK.
When included in a display-based platform, the standard SDK automatically incorporates all associated features into that platform. The following list shows the features that compose the standard SDK. In the next chapter desktop version of Shruti will be introduced and initially one of the modules of desktop Shruti is ported on an emulator running Windows CE with Standard SDK support. Some screenshots will show the primitive version of the Hindianalyser module ported on an emulator running Windows CE and supporting the standard software development kit.
2.2 Pocket-PC SDK (Software Development Kit)
After the primitive version on standard software development kit, the next version came on the Pocket-PC emulator running Windows CE and having a Pocket-PC software development kit. In Chapter 4 the details of the porting on Pocket-PC will be provided, but at this point of time an introduction to Pocket-PC software development kit is inevitable since this sdk is used to develop software for Pocket-PC platform very fast.
2.2.1 Introduction to Pocket PC 2002
Microsoft® Windows® Powered Pocket PC 2002 is a personal companion for mobile device users. It offers users the following:
• An easy, seamless setup experience
• An intuitive user interface
• Powerful information management
• A robust communications platform
• Customizable user interface
• Best companionship to Microsoft Outlook®
[pic]
2.2.2 Working with the Pocket PC 2002 Emulator
The Microsoft® Windows® Powered Pocket PC 2002 SDK includes a new emulation environment. This environment provides a virtual computer running Pocket PC 2002 software compiled for the Intel x86 processor. The virtual computer duplicates hardware that runs Microsoft Windows CE on an x86-based PC.
Previous Windows CE emulators relied on special emulator compilers that passed instructions to the underlying Microsoft Windows NT® operating system. This led to occasional dramatic differences in appearance and function between the emulator and a Pocket PC device. Because the new emulator is powered by the Windows CE operating system and by Pocket PC components, a much higher level of fidelity exists between an actual Pocket PC device and the device emulation environment.
New APIs: The Pocket PC 2002 platform supports the following newly exposed APIs.
• ActiveSync
This API provides ActiveSync 3.5 functionality for the Pocket PC 2002.
• Windows CE Messaging
This API provides a set of interfaces to facilitate the development of messaging applications for the Pocket PC 2002.
• Connection Manager
This API provides the functionality necessary to centralize and automate the establishment and management of the network connections on a Pocket PC 2002 device.
• HTML Control
This API provides the functionality to customize the HTML viewer control; this API also includes an XML parser.
• MIDI
This API provides the capability to play MIDI files on a Pocket PC 2002 device. This API also provides the functionality to create custom sounds such as a DTMF tone or a busy signal.
• Object Exchange (OBEX)
This API provides one method for transmitting information between two Pocket PC 2002 devices. The OBEX protocol requires fewer resources than an HTTP server and transfers information by using the infrared port on the Pocket PC 2002 device.
• Telephony
This API is a superset that includes the following sections:
o Assisted TAPI. Allows applications to make telephone calls without requiring the details of the services of the full Telephony API.
o Extended TAPI. Extends wireless functionality to include such things as asking for signal strength, choosing the cellular network, and more.
o Phone API. Provides the functionality to access a call log and creates a custom report from the information in that log.
o Subscriber Identity Module (SIM) Manager. Allows access to information stored on the SIM card.
o Short Message Service (SMS). Enables wireless devices to send and receive short messages through an SMS Center.
o Telephony Service Provider. Supports communications device control through a set of exported service functions.
Emulator: The Pocket PC 2002 SDK includes a new emulation environment. This environment provides a virtual machine running Pocket PC 2002 software compiled for the x86 processor. The virtual machine duplicates hardware known as a CEPC, which is a hardware configuration that runs Windows CE on an Intel x86-based PC.
2.2.3 Programming Pocket PC 2002
Microsoft® Windows® CE operating system version 3.0 for Windows Powered Pocket PC 2002 provides a powerful and easily portable platform for mobile professional users. It combines the power of a personal information manager (PIM), a compact
Software package fully compatible with Windows-based desktop computers, and a Windows development environment. Pocket PC 2002 allows users to keep their personal and business information up to date and close at hand by using a sophisticated hardware design to fill the need for a more portable and less expensive device than traditional laptop or palmtop computers.
Pocket PC 2002 is designed to quickly access, record, and transmit information at any time. The software bundled with Pocket PC 2002 manages contacts, appointments, and other personal and business information. By using the Voice Recorder application, users can capture ideas and thoughts as they occur. Pocket PC 2002 software can also store telephone numbers and short messages, and it can send and receive e-mail messages by using Internet technologies. All these features are fully compatible with the user's Windows-based desktop applications.
Pocket PC 2002 gives the developer access to a rich development environment. The Windows CE operating system is based on the Microsoft Win32® application programming interface. The applications can be created by using Microsoft eMbedded Visual Tools (eVT) 3.0, which are special versions of the familiar Microsoft Visual Studio® tools that the developers may have used to write applications for desktop Windows. The developer can choose to develop applications by using Microsoft eMbedded Visual C++® or Microsoft eMbedded Visual Basic®. Embedded Shurti is developed using Microsoft eMbedded Visual C++®.
Pocket PC 2002 supports a variety of input technologies, including freestyle drawing, handwriting character recognition, or a graphical representation of a keyboard for use on a touch screen.
2.2.4 Pocket PC 2002 Hardware
Original equipment manufacturers (OEMs) have a variety of hardware options when building Pocket PC 2002 devices. The following illustration shows the different hardware components available for a typical Pocket PC 2002.
[pic]
• Touch screen
The touch screen is an LCD covered by a resistive touch panel. The LCD has a portrait orientation with a 240 x 320 pixel resolution, which allows users to see interface elements clearly. The dot pitch for Pocket PC 2002 is.22 to .24, depending on the OEM. Tapping the touch screen with a stylus or finger sends the same kind of messages that clicking with the left mouse button does on a desktop computer, although cursor support is limited to a spinning hourglass for wait signals. The user can also select and drag items. In order to sense quick changes in user input, the touch screen has a refresh rate of at least 100 samples per second. Pocket PC 2002 also supports up to a 16 bit per pixel color depth.
• Stylus and keyboard
Pocket PC 2002 does not have a standard, physical keyboard. Text input is accomplished by using the input panel and the stylus. Generally, the input panel is a standard window on the touch screen that displays an input method, allowing users to enter data in a variety of ways. Pocket PC 2002 software includes a simplified QWERTY keyboard input method and a handwriting recognition input method.
The stylus is a pointer for accessing a touch screen and input methods. The stylus has a smaller point than a user's finger, yet will not scratch the touch screen.
The OEM or a user can add additional input methods. For example, an independent software vendor (ISV) could create an input method for tapping in Morse code. The user could purchase the Morse code input method and install it at home.
• Navigation controls
Pocket PC 2002 comes with several navigation controls, which can be pressed, held down, double-clicked, or pressed in combination with other controls. The following table shows the default Pocket PC 2002 navigation controls.
|Navigation control |Description |
|On/off |Turns Pocket PC 2002 on and off |
|Action button |Acts as the ENTER key |
|Record button |Activates the Voice Recorder application |
|Program button(s) |Launches an application |
|Up |Acts as an UP ARROW key |
|Down |Acts as a DOWN ARROW key |
Some OEMs may add a silkscreen region, which is an extension of the resistive touch panel, to cover a non-LCD region of a Pocket PC 2002 case. This region is usually directly below the LCD. It is called a silkscreen region because it often has buttons applied by using a silkscreen process. While a silkscreen button is technically a software control, Pocket PC 2002 software does not distinguish between a silkscreen button and other navigation controls; both types of buttons send the same virtual key messages. The OEM is responsible for the driver that handles the silkscreen region.
• Audio input
Depending on the device category, some Pocket PC 2002 devices will not support audio input or playback.
For devices that support audio, a built-in microphone is included. It is usually located on the front of the device, so that a user can view the screen while recording. The hardware supports 16-bit sampling at 8 kHz, and codec, the compression and decompression software, compresses the recording to 2.4 Kbps. The codec software is identical to a desktop computer's audio compression manager (ACM). OEMs may add a microphone jack for an external microphone. The jack is transparent to the software.
• Audio output
The developer can use the built-in speakers to play sounds associated with notification events. Speakers can also be used to play voice recordings or other .wav files, or for dual tone multifrequency (DTMF) dialing output. Some OEMs may add a headphone jack for headphones, external speakers, or other audio-out hardware. This jack is transparent to the software.
• Printing
Printing is not currently supported on the Pocket PC 2002.
• Notification options
An OEM may provide several notification options for a Pocket PC 2002: audio, a flashing LED, or vibration controls such as those on cellular phones and pagers. Although all three of these methods are supported by Pocket PC 2002, all except audio notification are OEM options.
• Power
Because a Pocket PC 2002 is portable, battery life is very important. Pocket PC 2002 can run many hours on its standard battery source, and also has a backup battery to avoid data loss if the primary battery loses power.
• CPU
Pocket PC 2002 uses the ARM family of CPUs. The ARM processors offer an excellent combination of high performance and low power consumption.
• Memory
All Pocket PC 2002 devices come with at least 24 megabytes (MB) of ROM and 16 MB of RAM. The upgrade edition offered by some OEMs for their Windows Powered Pocket PC devices is tailored to fit in the 16 MB of Flash RAM available on those upgradeable devices.
Because it is important to conserve memory on a Pocket PC 2002, many Pocket PC 2002 operating system (OS) components are compressed in ROM. When a user needs a component, the operating system decompresses that component and transfers it to RAM. Because of the time required for decompression and transfer, compressed files slow performance.
• Built-in serial port
Pocket PC 2002 comes with a built-in 16550 (or equivalent) serial port and some OEMs may include a second serial port. Applications use the serial port for communication between a Pocket PC 2002 and other hardware devices at baud rates from 19.2 kilobits per second (Kbps) to 115.2 Kbps. A Pocket PC 2002 can connect to a desktop computer by using a serial cable or an optional docking cradle, available from many Pocket PC 2002 manufacturers, that is connected to the desktop computer. Some Pocket PC 2002 devices support data communications through a modem connected to the cradle.
• Infrared communications serial port
Pocket PC 2002 includes a serial port that conforms to Infrared Data Association (IrDA) specifications. Pocket PC 2002 devices can communicate with other Pocket PC 2002 devices, other Windows CE devices, Palm™ OS-based handheld computing devices, or desktop computers.
2.3 Microsoft eMbedded Visual C++
Microsoft® eMbedded Visual C++ is a member of the Microsoft eMbedded Visual Tools 3.0 family of products which also has eMbedded Visual Basic. These products provide complete integrated development environments for creating applications to run on the Windows CE operating system.
2.3.1 Introduction
Microsoft® eMbedded Visual C++ enables programmers to develop Windows CE-based applications using an integrated development environment (IDE) similar to that used in developing desktop Visual C++ applications. This IDE, however, contains Windows CE-specific versions of many of the standard development tools that are used to create, test, and refine applications. It also includes a variety of tools that can be used to develop new software uniquely appropriate for Windows CE platforms and devices.
Custom-built for developing Windows CE applications, the eMbedded Visual C++ IDE is easy to learn and will be familiar to programmers who have experience with other members of the Visual C++ family. Applications can be created with eMbedded Visual C++ to run on the Handheld PC Pro (H/PC Pro), Palm-size PC 1.2, and Pocket PC platforms. The developers can also use eMbedded Visual C++ to create applications that run on custom Windows CE-based platforms, or within a desktop emulator that simulates a Windows-CE based platform. Embedded Shruti is coded using eMbedded Visual C++ for Pocket PC platform and tested on the Pocket PC emulator.
2.3.2 Managing Projects and Workspaces
In eMbedded Visual C++, applications are developed in a Workspace. Applications by assembled by either creating a project and a workspace simultaneously or by creating a workspace and then adding projects to it. After a workspace is created, the developer can add new projects, new configurations to an existing project, and subprojects. Microsoft eMbedded C++ development is characterized hierarchically by the workspace, projects, and subprojects.
• A workspace is a container for the development projects. When a new platform is created, a workspace is also created. Use Project view to look at and gain access to the various elements of projects. A workspace can contain multiple projects, including subprojects, but only one platform.
• A project is a configuration and a group of files that produce an application or final binary file(s).
• A subproject is a project that is dependent on another project. This dependency may consist of shared files, which need to be built in the subproject first, or it may include shared resources that need updating in the subproject first.
2.3.3 Developing an Application
After initially creating a project, developer can create the user interface. This involves first designing and creating dialog boxes, menus, toolbars, accelerators, and other visual and interactive elements, and then hooking them up to code. The user interface elements have to be tailored to the design requirements of the target device. For example, the Pocket PC is long and narrow (about 240x320 pixels), while the Handheld PC is larger (about 640x320 pixels). If the application is designed for the Pocket PC, dialogs will likely be too small for the Handheld PC. If the dialogs are designed for the Handheld PC, they will likely be cramped or not fit at all on the Pocket PC.
2.3.4 Building an Application
Microsoft eMbedded Visual C++ provides two ways of building an application. The easiest and most common way is to build within the eMbedded Visual C++ development environment. The other way is to build from the MS-DOS prompt using command-line tools. Building an application involves the preprocessor, the compiler, and the linker.
• The preprocessor prepares source files for the compiler by translating macros, operators, and directives.
• The compiler creates an object file containing machine code, linker directives, sections, external references, and function/data names.
• The linker combines code from the object files created by the compiler and from statically-linked libraries, resolves the name references, and creates an executable file.
2.3.5 The Build Process
The following diagram shows the components of the build process in eMbedded Visual C++ starting with the editor which can be used to write source code.
[pic]
If the program is built outside the IDE, the developer may use a makefile to invoke the command-line tools. Microsoft eMbedded Visual C++ provides the NMAKE utility for processing makefiles. If the program is built within the IDE, the eMbedded Visual C++ project system uses the project (.vcp) files to store make information. The .vcp files are not compatible with NMAKE. However, if the program uses a makefile rather than a .vcp file, it can still be built in the development environment as an external project.
2.3.6 Testing and debugging an application
Microsoft eMbedded Visual C++ provides tools to help test and debug applications. In the eMbedded Visual C++ options, the developer can choose to automatically or manually download the programs after building them to a connected device. When the developer has completed building a project configuration, the program can be run in eMbedded Visual C++ with or without debugging capabilities provided by the IDE. Running programs without using the debugging capabilities is faster because eMbedded Visual C++ does not have to load the debugger first. With the debugger however, breakpoints can be used and step through execution, inspect memory and registry values, check variables, observe message traffic and generally examine closely how the code works.
2.3.7 MFC for Windows CE
The Microsoft® Foundation Class (MFC) library for the Windows® CE operating system is both a mature, comprehensive class library and a complete object-oriented application framework designed to help the developer build applications, components, and controls for Windows CE-based platforms. The developer can use the Microsoft Foundation Classes for Windows CE to create anything from a simple dialog box-based application to a sophisticated application that employs the full MFC document/view architecture. MFC can also be used for Windows CE to create full-featured Microsoft® ActiveX® controls and ActiveX containers.
The developers who have experience using MFC for desktop applications will find MFC for Windows CE very similar and the migration to MFC for Windows CE will be smooth.
MFC supports a number of classes to help the developers write applications using those utility classes. For example if the developer wants to use a hash data structure then there is no need to design the data structure from scratch. Instead the developer can use a CMap class already defined in MFC and the application will be made quite fast.
Microsoft Foundation Classes provides a framework of a number of utility classes and provides the developer with a number of programming options.
Microsoft® eMbedded Visual C++® 3.0 toolkits contain all the development tools and wizards needed for building MFC for Windows CE applications. Several MFC classes are used in the design of Embedded Shruti and the details of the classes will be provided in Chapter 4 which explains the design of Embedded Shruti.
2.4 Microsoft SQL server CE
During the development phase of Embedded Shruti, Microsoft SQL server for CE was considered as an option for providing database support to the application. This section will explain some of the key features of the Microsoft SQL server CE and the reason why it was not used in Embedded Shruti.
2.4.1 Rapid Application Development
SQL Server CE makes application development easy while providing a consistent development model and API set. Microsoft® Visual Basic® developers can rapidly develop Windows CE applications by using eMbedded Visual Basic and ADOCE (ActiveX data objects from Windows CE). Microsoft® Visual C++® developers can leverage their existing skills to build sophisticated Windows CE-based database applications that target mobile and embedded solutions.
2.4.2 High-Performance Database Engine
SQL Server CE offers rich relational database functionality in the small memory footprint on today's devices. Microsoft SQL Server developers will appreciate the robust feature set which includes:
• A compatible SQL grammar with SQL Server 2000. Statements that run on SQL Server CE will, in general, run on SQL Server.
• A wide range of data types, including:
• TINYINT, SMALLINT, INTEGER, BIGINT
• REAL, NUMERIC, FLOAT
• BIT, BINARY, VARBINARY, IMAGE
• UNICODE character data types NATIONAL CHARACTER, NATIONAL CHARACTER VARYING, NTEXT
• MONEY, DATETIME, UNIQUEIDENTIFIER
• 32 indexes per table, multicolumn indexes
• NULL support
• Nested transactions
• 128-bit file level encryption
• DDL: Create databases, alter tables, referential integrity, default values
• DML: INSERT, UPDATE, DELETE
• SELECT: SET Functions (aggregates), INNER/OUTER JOIN, subselect, GROUP BY/HAVING
• Scrollable and forward-only cursors
Hardware and Software Requirements
Hardware Requirements
|Platform |Requirements |
|SQL Server system |See the operating system requirements in SQL Server Books Online. |
|IIS system |120 MB of available disk space. |
|Development system |30 MB of available disk space. The computer will need an additional 30 MB |
| |of temporary storage space for the setup files. |
|Windows CE device |Between 1 and 3 MB of available storage space, depending on processor type |
| |and components installed. |
| |The file sizes for the SQL Server CE components vary by processor type and |
| |Windows CE operating system version. Hard disk space requirements also |
| |depend on which SQL Server CE components are installed. |
Operating System Requirements
|Platform |Supported operating systems |
|SQL Server system |See the operating system requirements in the SQL Server Books Online. |
|Development system |Microsoft Windows 98 Second Edition, Microsoft Windows Millennium (Me), |
| |Microsoft Windows NT® 4.0 with Service Pack 5 or later, or Microsoft |
| |Windows 2000. |
| |Windows CE desktop emulation requires Windows NT 4.0 or Windows 2000. |
| |Emulation is not supported on Windows 98. |
| |Microsoft ActiveSync 3.1 or later. |
|IIS system |Windows NT 4.0 with Service Pack 5 or later, or Windows 2000. |
|Windows CE device |Windows CE version 2.11 or later. |
SQL Server Requirements
|SQL Server |Supported SQL Server CE features |
|SQL Server 2000 |All features are supported including merge replication and RDA. |
|SQL Server version 6.5 with Service Pack 5 or later and |RDA is supported; replication is not supported. |
|SQL Server 7.0 | |
Internet Information Services and Internet Explorer Requirements
|Component |Requirements |
|Microsoft Internet Explorer 5.0 |Internet Explorer 5.0 or later is required on the development system to |
| |access SQL Server CE HTML Help. |
| |Internet Explorer 5.0 or later is required on IIS system. |
|IIS |Replication and RDA require IIS 4.0 on Windows NT 4.0 or IIS 5.0 on Windows|
| |2000. |
ActiveSync Requirements
|Component |Requirements |
|SSCERelay.exe |Windows 98 Second Edition, Windows Millennium (Me), Windows NT 4.0 with |
| |Service Pack 5 or later, or Windows 2000. |
Windows CE Requirements
|Platform |Windows CE operating system version |
|Handheld PC Pro (H/PC Pro) |2.11 or later |
|Palm-size PC (P/PC) |2.11 or later |
|Pocket PC |3.0 or later |
|HPC 2000 |3.0 or later* |
2.4.3 Drawbacks of SQL server (Windows CE version)
The tables showed above gives a complete reference to the hardware and software requirements for SQL server for CE. Take a look at the Windows CE device requirement. Depending on the processor type and components installed, 1 MB to 3 MB of storage space is required on the Windows CE device.
On the top of that Embedded Shruti doesn’t need a database that supports extensible set of SQL statements. Queries are made only by sending a key rather than writing the SQL statements. Keeping this design issue in mind, using SQL server for Windows CE will just eat up the resources while not producing any significant gain. For an embedded application 1 MB space (minimal Windows CE installation) is quite large. The application needed an extendible hashing based database which would save the database values according to the key field and then retrieve the values efficiently. Extendible hashing is an efficient implementation since retrieval is having a complexity of O (1+alpha) where alpha is the load factor. For balanced hash tables the retrieval will give better performance than SQL server for Windows CE which have to process the SQL queries involving extra overhead. A well known hash based database called GDBM which is quite popular on UNIX platform is ported on Windows CE platform and used in Embedded Shruti. Thus Embedded Shruti uses a variant of GNU software and thus is a merger of Microsoft technologies and Open source GDBM project.
The next section will introduce the GDBM (GNU Database Manager) in general.
2.5 GNU Database Manager (popularly called GDBM)
GDBM - The GNU database manager is a set of database routines that use extensible hashing.
2.5.1 Synopsis
#include // This file contains all the function and data type definitions for
// GDBM
extern gdbm_error
gdbm_errno
extern char
*gdbm_version
GDBM_FILE
gdbm_open (name, block_size, read_write, mode, fatal_func)
char * name;
int block_size, read_write, mode;
void (*fatal_func) ();
void
gdbm_close (dbf)
GDBM_FILE dbf;
int
gdbm_store (dbf, key, content, flag)
GDBM_FILE dbf;
datum key, content;
int flag;
datum
gdbm_fetch (dbf, key)
GDBM_FILE dbf;
datum key;
int
gdbm_delete (dbf, key)
GDBM_FILE dbf;
datum key;
datum
gdbm_firstkey (dbf)
GDBM_FILE dbf;
datum
gdbm_nextkey (dbf, key)
GDBM_FILE dbf;
datum key;
int
gdbm_reorganize (dbf)
GDBM_FILE dbf;
void
gdbm_sync (dbf)
GDBM_FILE dbf;
int
gdbm_exists (dbf, key)
GDBM_FILE dbf;
datum key;
char *
gdbm_strerror (errno)
gdbm_error errno;
int
gdbm_setopt (dbf, option, value, size)
GDBM_FILE dbf;
int option;
int *value;
int size;
2.5.2 Description
GNU dbm is a library of routines that manages data files that contain key/data pairs. The access provided is that of storing, retrieval, and deletion by key and a non-sorted traversal of all keys. A process is allowed to use multiple data files at the same time.
A process that opens a gdbm file is designated as a "reader" or a "writer". Only one writer may open a gdbm file and many readers may open the file. Readers and writers can not open the gdbm file at the same time. The procedure for opening a gdbm file is:
GDBM_FILE dbf;
dbf = gdbm_open ( name, block_size, read_write, mode, fatal_func )
Name is the name of the file (the complete name, gdbm does not append any characters to this name). Block_size is the size of a single transfer from disk to memory. This parameter is ignored unless the file is a new file. The minimum size is 512. If it is less than 512, dbm will use the stat block size for the file system. Read_write can have one of the following values:
GDBM_READER reader
GDBM_WRITER writer
GDBM_WRCREAT writer - if database does not exist create new one
GDBM_NEWDB writer - create new database regardless if one exists
For the last three (writers of the database) there is an extra value that that can be added to read_write by bitwise or, GDBM_FAST. This requests that gdbm write the database with no disk file syncronization. This allows faster writes, but may produce an inconsistant database in the event of abnormal termination of the writer.
Mode is the file mode (Read, Write or both) if the file is created. (*Fatal_func) () is a function for dbm to call if it detects a fatal error. The only parameter of this function is a string. If the value of 0 is provided, gdbm will use a default function.
The return value dbf is the pointer needed by all other routines to access that gdbm file. If the return is the NULL pointer, gdbm_open was not successful. The errors can be found in gdbm_errno for gdbm errors and in errno for system errors. (For error codes, refer to gdbmerrno.h)
In all of the following calls, the parameter dbf refers to the pointer returned from gdbm_open.
It is important that every file opened is also closed. This is needed to update the reader/writer count on the file. This is done by:
gdbm_close (dbf);
The database is used by 3 primary routines. The first stores data in the database.
ret = gdbm_store ( dbf, key, content, flag )
Dbf is the pointer returned by gdbm_open. Key is the key data. Content is the data to be associated with the key. Flag can have one of the following values:
GDBM_INSERT insert only, generate an error if key exists
GDBM_REPLACE replace contents if key exists.
If a reader calls gdbm_store, the return value will be -1. If called with GDBM_INSERT and key is in the database, the return value will be 1. Otherwise, the return value is 0.
If the data is stored for a key that is already in the data base, gdbm replaces the old data with the new data if called with GDBM_REPLACE. Two data items for the same key are not obtained and there is no error from gdbm_store.
To search for some data:
content = gdbm_fetch ( dbf, key )
Dbf is the pointer returned by gdbm_open. Key is the key data.
If the dptr element of the return value is NULL, no data was found. Otherwise the return value is a pointer to the found data. The storage space for the dptr element is allocated using malloc. Gdbm does not automatically free this data. It is the programmer's responsibility to free this storage when it is no longer needed.
To search for some data, without retrieving it:
ret = gdbm_exists ( dbf, key )
Dbf is the pointer returned by gdbm_open. Key is the key data to search for.
If the key is found within the database, the return value ret will be true. If nothing appropiate is found, ret will be false. This routine is useful for checking for the existance of a record, without performing the memory allocation done by gdbm_fetch.
To remove some data from the database:
ret = gdbm_delete ( dbf, key )
Dbf is the pointer returned by gdbm_open. Key is the key data.
The return value is -1 if the item is not present or the requester is a reader. The return value is 0 if there was a successful delete.
The next two routines allow for accessing all items in the database. This access is not key sequential, but it is guaranteed to visit every key in the database once. (The order has to do with the hash values.)
key = gdbm_firstkey ( dbf )
nextkey = gdbm_nextkey ( dbf, key )
Dbf is the pointer returned by gdbm_open. Key is the key data.
The return values are both of type datum. If the dptr element of the return value is NULL, there is no first key or next key. Again notice that dptr points to data allocated by malloc and gdbm will not free it for the developer.
These functions were intended to visit the database in read-only algorithms, for instance, to validate the database or similar operations.
File `visiting' is based on a `hash table'. gdbm_delete re-arranges the hash table to make sure that any collisions in the table do not leave some item `un-findable'. The original key order is NOT guaranteed to remain unchanged in ALL instances. It is possible that some key will not be visited if a loop like the following is executed:
key = gdbm_firstkey ( dbf );
while ( key.dptr ) {
nextkey = gdbm_nextkey ( dbf, key );
if ( some condition ) {
gdbm_delete ( dbf, key );
free ( key.dptr );
}
key = nextkey;
}
The following routine should be used very infrequently.
ret = gdbm_reorganize ( dbf )
If there are a lot of deletions and the developer would like to shrink the space used by the gdbm file, this routine will reorganize the database. Gdbm will not shorten the length of a gdbm file except by using this reorganization. (Deleted file space will be reused.)
If GDBM_FAST value is used in gdbm_open call, the following routine can be used to guarantee that the database is physically written to the disk file.
gdbm_sync ( dbf )
It will not return until the disk file state is syncronized with the in-memory state of the database.
To convert a gdbm error code into English text, use this routine:
ret = gdbm_strerror ( errno )
Where errno is of type gdbm_error, usually the global variable gdbm_errno. The appropiate phrase is returned.
gdbm now supports the ability to set certain options on an already open database.
ret = gdbm_setopt ( dbf, option, value, size )
Where dbf is the return value from a previous call to gdbm_open, and option specifies which option to set. The valid options are currently:
GDBM_CACHESIZE: Set the size of the internal bucketcache. This option may only be set once on each GDBM_FILE descriptor, and is set automatically to 100 upon the first access to the
database.
GDBM_FASTMODE:
Set fast mode to either on or off. This allows fast mode to be toggled on an already
open and active database. value (see below) should be set to either TRUE or FALSE.
value is the value to set option to, specified as an integer pointer. size is the size of the data pointed to by value. The return value will be -1 upon failure, or 0 upon success. The global variable gdbm_errno will be set upon failure.
For instance, to set a database to use a cache of 10, after opening it with gdbm_open, but prior to accessing it in any way, the following code could be used:
int value = 10;
ret = gdbm_setopt( dbf, GDBM_CACHESIZE, &value, sizeof(int));
The following two external variables may be useful:
gdbm_errno is the variable that contains more information about gdbm errors. (gdbm.h has the definitions of the error values and defines gdbm_errno as an external variable.)
gdbm_version is the string containing the version information
This gives an introduction to GNU Database manager. Embedded Shruti has used a version of GDBM ported into Windows CE so that it can be used by Pocket-PC Software Development Kit. Details of the GDBM functions used in Embedded Shruti will be provided in Chapter 4 which explains the complete design of Embedded Shruti.
Chapter 3
Shruti: Desktop Version
In recent years, it has become critical to bridge the gulf of between the man and the machine. The Internet has become an integral part of today’s life and the greatest knowledge repository on Earth. Technology for accessing the Internet and harnessing the myriad powers of the personal computer is a must if one is not to fall behind. The need of the hour is intelligent human-computer interfacing, enabling a wider community such as the rural neo-literates and pre-literates, the physically challenged (like the visually impaired and the speech impaired) to interact with computer systems in a natural way.
The speech interfaces like Shruti may have manifold uses. They could serve as:
• Computer interfaces for the visually challenged, for whom graphical interfaces are not viable.
• The voice of the speech impaired.
• Computer interfaces for neo-literates and pre-literates.
• Modules in software to help pre-literates learn languages using a computer.
• Interfacing modules in multilingual environments, where, depending on the need, the computer can talk in different languages.
Text to speech has been one of the greatest challenges of modern computational science. While the utterance of flat speech by a computer has been achievable – the greatest challenges in the field are to impose natural intonation and prosody based on the characteristics of the language, dialect, person and context.
The diagram shown below gives a complete idea of the modules of a Text to Speech converter. The diagram is detailed and gives a clear idea of a TTS converter:
[pic]
Various techniques exist to convert a given text to speech. Initially, a grapheme to phoneme mapper is required to convert the given graphemes (the smallest unit of written language) to a list of phonemes (the smallest unit of spoken language). The next stage is to render the string of phonemes – to synthesize the speech. Speech synthesizers can be broadly classified into two different classes. Some synthesizers are articulatory where speech synthesis is controlled by parameters that represent the speech production system rather than the signal itself, the other being concatenative synthesizers where different signal units from a dictionary are concatenated to produce synthetic speech. However, the prime challenge in all cases is the quality of the sound produced and its naturalness.
The desktop version of Shruti implements the Text-to-Speech converter for regional languages like Hindi and Bengali using concatenative approach. Concatenative approach finds voice units corresponding to a Phoneme and concatenates them to produce the sound file. Smoothening algorithms are also applied on the concatenated speech and the noted improvements are achieved in this process.
After understanding the basic essence of Text-to-Speech software let’s quickly understand how the desktop version of Shruti is implemented.
3.1 Features of Shruti
1. The front-end of the software is written using Java. Refer to the block diagram shown above. The front-end is used to take the input text and produce the output sound file. The processing is done by two backend dynamic link libraries.
2. There are two backend dynamic link libraries that are written using C++ and which implements two important parts of the Text-to-Speech synthesizer.
3. The first dynamic link library implements the Natural Language Processing (NLP) unit which will be referred as Hindianalyser module in remaining thesis.
4. The second dynamic link library implements the Indian Language Phonetic Synthesizer (ILPS) unit which will be referred as Hindiengine module in remaining thesis.
5. These dynamic link libraries are loaded at the runtime when required and the
appropriate functions from the library will be called.
3.2 Overview of Shruti
The processing part of the desktop based (Win32 API) text-to-speech software can be divided into 2 sub modules:
• HindiAnalyser: It takes the input supplied by the frontend to produce tokens which corresponds to a unique sound clip of the sound library.
• HindiEngine: It takes the tokens and sound units from the library and generates the whole sound clip. After generation smoothening algorithms are applied for a smooth speech.
The frontend is responsible to take the input and to play the wav file generated by the backend.
The next figure shows a dataflow diagram for the software. Dataflow diagrams always facilitate the understanding of a software product.
[pic]
3.3 Technologies used
The front-end is written using Java and an important feature of this implementation is to call the dynamic link libraries made by Visual C++ from Java program. This is done using Java Native Interfaces. In the code for the dynamic link library made by Visual C++, the following code snippet is added:
JNIEXPORT void JNICALL
Java_hindidisplay_Analyse (JNIEnv *env, jobject obj)
This function of the dll can be accessed from the java code. Two files called “jni.h” and “jni_md.h” are included during the build process. See the references to find the source code of this implementation.
3.4 Comparisons
1. Java Developer Kit (JDK) should be installed on the desktop computer running the software. JDK is bulky software so it is not possible to use JDK for Embedded Shruti where memory is a main concern and in such a case installing JDK is more of a burden than of any substantial use. Therefore Embedded Shruti uses Windows CE API and Microsoft Foundation Classes customized for Windows CE. Such an implementation don’t need any JDK on the hardware (Pocket-PC in this case) on which the software will be executed.
2. Now in the implementation completely using Windows CE API and MFC customized for Windows CE a dynamic link library (mfcce400d.dll) of size 819 KB is required which is considerably smaller than the JDK. The JDK for Windows CE with least features has a size of 8.5 MB.
3. The backend dlls are made using Embedded Visual C++ and transferred on the system folder of the device running Windows CE.
Win CE Hindianalyser dll: 43 KB Win32 version : 256 KB
Win CE Hindiengine dll: 29 KB Win32 version : 260 KB
4. The next design issue was to choose a database. A SQL server for Windows CE
would have required at least 1 MB of memory. But the port of GDBM to Windows CE which is used in Embedded Shruti require only a dynamic link library called gdbmce.dll which is of size 31KB and it is appropriate for the application since a hash based structure was needed rather than a database which implements SQL queries.
The names and the sizes of the dynamic link libraries that will be needed to run Embedded Shruti are the following:
1. gdbmce.dll ( 31 KB (for database application)
2. hindianalyser.dll ( 43 KB NLP module
3. hindiengine.dll ( 29 KB ILPS module
4. mfcce400d.dll ( 819 KB (for standard SDK emulation)
5. mfcce300.dll + mfcce300d.dll ( 289 KB+ 846KB (for Pocket PC emulation)
This data shows that this implementation needs much less disk space compared to an implementation that uses JDK and build the software on top of it.
The next chapter will explain the different implementations of Embedded Shruti one by one and the key features of each implementation will be provided. Each implementation is referred as a model. The performance comparison will be provided subsequently.
Chapter 4
Embedded Shruti
Last chapter introduced the desktop version of Shruti and the structure of the source code was explained along with the dataflow diagram for the software. In this chapter different models of Embedded Shruti will be explained one by one and the drawbacks of each model will be sited which resulted into a new modified and efficient model.
4.1 Model 1: Windows CE crude port
This is the first model of Embedded Shruti. It started with the source code of Win32 version and first of all the structure of the native source code is identified. The points are identified where the API functions that are used in native code are not supported in Windows CE API. At all these points the modifications will be done accordingly so that the native code remains consistent. The input output characteristic of the native code should not be changed.
Embedded Shruti is designed in a modular way. There are three modules in Model 1. These are the following:
1. Frontend
2. Hindianalyser
3. Hindiengine
Frontend was designed using Java in the native Win32 code but in Embedded Shruti it’s designed using MFC customized for Windows CE in eMbedded Visual C++.
The Frontend has a dialog box having the following contents:
1. Input Text Box: It takes the text input from the user which is to be changed to speech. The input should be in Hindi/Bengali at present. If multilingual keyboard is not there spell the Bengali/Hindi words using English alphabets and then fed the English alphabets into the text box.
2. Analyse Button: Analyse button on clicking read the input text from the text box and then write the text into a temporary file on the device called “TextIscii.txt”. This file will be read later on by the dynamic link library. Now after saving the input text on a file it loads the dynamic link library for Natural Language Processing called as hindianalyser.dll. Code snippet for loading dll is provided. The dll should export the functions which other executable can call. The method of exporting the functions from a dll will be given shortly. Before that the procedure to load a dll and call an exported function from executable code is given.
//Define a function pointer to call the DLL function
typedef int(*MBFuncPtr)(DWORD cBytes);
This is a pointer to a function whose return type is integer and which takes as input a DWORD. DWORD is a datatype defined in MFC. This refers to positive integers.
//Instance variable required to load a library
HINSTANCE hInst1;
//Loading a dynamic link library
hInst1 = ::LoadLibrary(L"hindianalyser.dll");
if(hInst1 == NULL)
MessageBox(L"Unable to load the analyser library");
else
MessageBox(L"Analyser Library successfully loaded");
If the library is not loaded successfully then hInst1 will be null. Once the library is loaded into the main memory the exported function from the library is accessed using the function pointer. The functions exported from the dynamic link libraries can be accessed only by the function pointer.
//Getting the address of the analyser function into the function pointer
MBFuncPtr pFunction=(MBFuncPtr)GetProcAddress(hInst1,L"Analyse");
Analyse is the name of the function exported from the dynamic link library. The functions that were exported by the dynamic link library are mentioned on .def(definition) file of the dynamic link library source code. A typical .def file will look like:
//analyser.def
LIBRARY Analyser
EXPORTS
Analyse
The name of the library is specified on the first line of the def file which is called Analyser library in this case. After that there are a list of functions that are exported from the dll which are mentioned under the EXPORTS header. There may be a number of function exported by a dll. There should be a function in dll that starts with the name as mentioned under EXPORTS tag. The pointer to that function will be copied into the function pointer from the calling program (the executable in this case) and the function is called with appropriate inputs.
pFunction called above will be NULL if there is no such function exported by the dll.
if(pFunction = = NULL)
MessageBox(L"Unable to load the Analyse function");
else
{
MessageBox(L"Analyse function exported from the dll called");
tokenLength=(*pFunction)(cBytes);
}
Once the function pointer is obtained in pFunction, the function can be called with DWORD as parameter and as the return type is integer it will return an integer value after processing the input text file “TextAscii.txt”.
After the use of library is over it’s always advisable to Free the library. As the dynamic link libraries are loaded on RAM, for devices running Windows CE which have very limited RAM space it’s advisable to unload the dll as soon as the work is done.
//Unloading a dynamic link library
::FreeLibrary(hInst1);
The methods discussed above a necessary to do operations related to dynamic link libraries. The next important difference between the native Win32 source code and the Windows CE version are the file operations. As already mentioned above on clicking the Analyse button the text input is saved on a file in disk. Windows CE doesn’t support file operations like fopen, fread, fclose, fseek and so on. Therefore while porting it is very important to find the equivalent of each of these file operations using Windows CE API.
In Windows CE API all devices are accessed by handles. The developer can access a file on disk, or a USB port or a sound device using handles. No other layer is defined like fopen and fseek. The following code snippets will show how to create a file, read a file and write a file using Windows CE API.
//To create a file
HANDLE exampleHandle = 0;
//Create a file in read mode
exampleHandle = CreateFile
(L"TextIscii.txt",GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
//Create a file in write mode
exampleHandle= CreateFile(L"TextIscii.txt",GENERIC_WRITE,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
A complete reference to the CreateFile function is provided below:
This function creates, opens, or truncates a file, communications resource, disk device, or console. It returns a handle that can be used to access the object. It can also open and return a handle to a directory.
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDispostion ,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile );
Parameters
lpFileName
Pointer to a null-terminated string that specifies the name of the object (file, communications resource, disk device, console, or directory) to create or open.
If *lpFileName is a path, there is a default string size limit of MAX_PATH characters. This limit is related to how the CreateFile function parses paths.
When lpFileName points to a communications resource to open, the developer must include a colon after the name. For example, specify "COM1: " to open that port.
dwDesiredAccess
Specifies the type of access to the object. An application can obtain read access; write access, read-write access, or device query access. This parameter can be any combination of the following values.
|Value |Description |
|0 |Specifies device query access to the object. An application can query |
| |device attributes without accessing the device. |
|GENERIC_READ |Specifies read access to the object. Data can be read from the file and |
| |the file pointer can be moved. Combine with GENERIC_WRITE for read-write|
| |access. |
|GENERIC_WRITE |Specifies write access to the object. Data can be written to the file |
| |and the file pointer can be moved. Combine with GENERIC_READ for |
| |read-write access. |
dwShareMode
Specifies how the object can be shared. If dwShareMode is 0, the object cannot be shared. Subsequent open operations on the object will fail, until the handle is closed.
To share the object, use a combination of one or more of the following values:
|Value |Description |
|FILE_SHARE_READ |Subsequent open operations on the object will succeed only if read |
| |access is requested. |
|FILE_SHARE_WRITE |Subsequent open operations on the object will succeed only if write |
| |access is requested. |
lpSecurityAttributes
Ignored; set to NULL.
dwCreationDispostion
Specifies which action to take on files that exist, and which action to take when files do not exist. For more information about this parameter, see the Remarks section. This parameter must be one of the following values:
|Value |Description |
|CREATE_NEW |Creates a new file. The function fails if the specified file already |
| |exists. |
|CREATE_ALWAYS |Creates a new file. If the file exists, the function overwrites the file|
| |and clears the existing attributes. |
|OPEN_EXISTING |Opens the file. The function fails if the file does not exist. |
|OPEN_ALWAYS |Opens the file, if it exists. If the file does not exist, the function |
| |creates the file as if dwCreationDisposition were CREATE_NEW. |
|TRUNCATE_EXISTING |Opens the file. Once opened, the file is truncated so that its size is |
| |zero bytes. The calling process must open the file with at least |
| |GENERIC_WRITE access. The function fails if the file does not exist. |
dwFlagsAndAttributes
Specifies the file attributes and flags for the file.
Any combination of the following attributes is acceptable for the dwFlagsAndAttributes parameter, except all other file attributes override FILE_ATTRIBUTE_NORMAL.
|Value |Description |
|FILE_ATTRIBUTE_ARCHIVE |The file should be archived. Applications use this attribute to |
| |mark files for backup or removal. |
|FILE_ATTRIBUTE_HIDDEN |The file is hidden. It is not to be included in an ordinary |
| |directory listing. |
|FILE_ATTRIBUTE_NORMAL |The file has no other attributes set. This attribute is valid |
| |only if used alone. |
|FILE_ATTRIBUTE_READONLY |The file is read only. Applications can read the file but cannot|
| |write to it or delete it. |
|FILE_ATTRIBUTE_SYSTEM |The file is part of or is used exclusively by the operating |
| |system. |
|FILE_ATTRIBUTE_TEMPORARY |Not supported. |
hTemplateFile
Ignored; as a result, CreateFile does not copy the extended attributes to the new file.
Return Values
An open handle to the specified file indicates success. If the specified file exists before the function call and dwCreationDisposition is CREATE_ALWAYS or OPEN_ALWAYS, a call to GetLastError returns ERROR_ALREADY_EXISTS, even though the function has succeeded. If the file does not exist before the call, GetLastError returns zero. INVALID_HANDLE_VALUE indicates failure. To get extended error information, call GetLastError.
//Read a file
The file can be read by the handler only if it is opened in GENERIC_READ mode using CreateFile. Thus the call to read file must come after the file is opened appropriately.
ReadFile(exampleHandler,rbuff,cBytes,&readBytes,NULL);
Here the file is read into the character array rbuff where cBytes specifies number of bytes to be read and readBytes will contain the number of bytes actually read from the file. readBytes is passed by address so that it can be modified in ReadFile and the modifications will be visible in the calling function.
API reference to ReadFile:
This function reads data from a file, starting at the position indicated by the file pointer. After the read operation has been completed, the file pointer is adjusted by the number of bytes actually read.
BOOL ReadFile(
HANDLE hFile,
LPVOID lpBuffer,
DWORD nNumberOfBytesToRead,
LPDWORD lpNumberOfBytesRead,
LPOVERLAPPED lpOverlapped );
Parameters
hFile
Handle to the file to be read. The file handle must have been created with GENERIC_READ access to the file. This parameter cannot be a socket handle.
lpBuffer
Pointer to the buffer that receives the data read from the file.
nNumberOfBytesToRead
Number of bytes to be read from the file.
lpNumberOfBytesRead
Pointer to the number of bytes read. ReadFile sets this value to zero before doing any work or error checking.
lpOverlapped
Unsupported; set to NULL.
Return Values
The ReadFile function returns when one of the following is true: the number of bytes requested has been read or an error occurs.
Nonzero indicates success. If the return value is nonzero and the number of bytes read is zero, the file pointer was beyond the current end of the file at the time of the read operation. Zero indicates failure. To get extended error information, call GetLastError.
//Write to a file
The file can be read by the handler only if it is opened in GENERIC_WRITE mode using CreateFile. Thus the call to read file must come after the file is opened appropriately.
WriteFile (exampleHandler,wbuff,cBytes,&writeBytes,NULL);
Here the character array wbuff is written into the file specified by the exampleHandler where cBytes specifies number of bytes to be written and writeBytes will contain the number of bytes actually written into the file. writeBytes is passed by address so that it can be modified in WriteFile and the modifications will be visible in the calling function.
API Reference to WriteFile:
This function writes data to a file. WriteFile starts writing data to the file at the position indicated by the file pointer. After the write operation has been completed, the file pointer is adjusted by the number of bytes actually written.
BOOL WriteFile(
HANDLE hFile,
LPCVOID lpBuffer,
DWORD nNumberOfBytesToWrite,
LPDWORD lpNumberOfBytesWritten,
LPOVERLAPPED lpOverlapped );
Parameters
hFile
Handle to the file to be written to. The file handle must have been created with GENERIC_WRITE access to the file.
lpBuffer
Pointer to the buffer containing the data to be written to the file.
nNumberOfBytesToWrite
Number of bytes to write to the file.
A value of zero specifies a null write operation. A null write operation does not write any bytes but does cause the time stamp to change. WriteFile does not truncate or extend the file. To truncate or extend a file, use the SetEndOfFile function.
Named pipe write operations across a network are limited to 65,535 bytes.
lpNumberOfBytesWritten
Pointer to the number of bytes written by this function call. WriteFile sets this value to zero before doing any work or error checking.
lpOverlapped
Unsupported; set to NULL.
Return Values
Nonzero indicates success. Zero indicates failure. To get extended error information, call GetLastError.
Remarks
If part of the file is locked by another process and the write operation overlaps the locked portion, this function fails.
Accessing the output buffer while a write operation is using the buffer may lead to corruption of the data written from that buffer. Applications must not read from, write to, reallocate, or free the output buffer that a write operation is using until the write operation completes.
After understanding the basic operations to Create, Read or Write in file in Windows CE, the crude way of porting is to replace all the file operations like fopen, fread, fwrite, fclose, fseek by the CreateFile, ReadFile and WriteFile.
The following diagram shows the file operations done in the hindianalyser native code which are replaced by CreateFile, ReadFile and WriteFile operations to make it compatible with Windows CE API.
As discussed above clicking the Analyse button takes the input and invokes hindianalyser dll and return the number of tokens written in tokens file.
[pic]
Each file operation is implemented using the Windows CE API now. After this stage the tokens are saved in a file Tokens.txt on disc. The file contains token in this form:
1. The token name: For example token name can be 0704 which is the name of the sound file corresponding to this token and which will be obtained in the hindiengine phase.
2. The token type: Token type specifies that whether this is a vowel or a consonant and on the basis of that the sound generation algorithm works.
Please look at the references to know the algorithms used in Shruti which are also used in the Embedded version.
Another important difference between Win32 API and Windows CE API is the memory allocation techniques. C type memory allocation (malloc) doesn’t work on Windows CE API. The following function should be used in place of that:
char *s;
s = (char *)LocalAlloc(LMEM_FIXED,cBytes);
LocalAlloc allocate memory on local heap of size cBytes and returns a pointer that is stored in s. Local heap is always there in Windows CE by default. But the developer can declare heaps on their own and write efficient memory code.
3. Generate button: On clicking the generate button first of all the Hindiengine library is loaded into the main memory. After that the exported function from the Hindiengine library is called with tokenLength as the input where tokenLength is the number of bytes in the Tokens.txt file. Generate function from the dll read the Token.txt file, retrieve the tokens and token type from the file and then concatenates the sound files according to tokens into one file.
For example if token is 0704, then it will retrieve the sound file 0704.wav from a sound library (in this model the sound library is a directory which contains all the sound files)
Thus for all tokens the sound files will be read from the directory, appropriately concatenated and the output sound file will be produced.
In this dll Windows CE counterpart for fread, fwrite and fseek were written which will be given shortly but before that the last function of the generate button click is to play the sound file generated by the dll function.
//Code to play a wav format file on Windows CE
MMRESULT PlayWave(LPCTSTR szWavFile)
{
HWAVEOUT hwo;
WAVEHDR whdr;
MMRESULT mmres;
CWaveFile waveFile;
HANDLE hDoneEvent = CreateEvent(NULL, FALSE, FALSE, TEXT("DONE_EVENT"));
UINT devId;
DWORD dwOldVolume;
// Open wave file
if (!waveFile.Open(szWavFile)) {
TCHAR szErrMsg[MAX_ERRMSG];
_stprintf (szErrMsg, TEXT("Unable to open file: %s\n\n"),szWavFile);
MessageBox(NULL, szErrMsg, TEXT("File I/O Error"), MB_OK);
return MMSYSERR_NOERROR;
}
// Open audio device
for (devId = 0; devId < waveOutGetNumDevs(); devId++) {
mmres = waveOutOpen(&hwo, devId, waveFile.GetWaveFormat(), (DWORD) hDoneEvent,
0, CALLBACK_EVENT);
if (mmres == MMSYSERR_NOERROR) {
break;
}
}
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
// Set volume
mmres = waveOutGetVolume(hwo, &dwOldVolume);
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
waveOutSetVolume(hwo, 0xFFFFFFFF);
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
// Initialize wave header
ZeroMemory(&whdr, sizeof(WAVEHDR));
whdr.lpData = new char[waveFile.GetLength()];
whdr.dwBufferLength = waveFile.GetLength();
whdr.dwUser = 0;
whdr.dwFlags = 0;
whdr.dwLoops = 0;
whdr.dwBytesRecorded = 0;
whdr.lpNext = 0;
whdr.reserved = 0;
// Play buffer
waveFile.Read(whdr.lpData, whdr.dwBufferLength);
mmres = waveOutPrepareHeader(hwo, &whdr, sizeof(WAVEHDR));
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
mmres = waveOutWrite(hwo, &whdr, sizeof(WAVEHDR));
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
// Wait for audio to finish playing
while (!(whdr.dwFlags & WHDR_DONE)) {
WaitForSingleObject(hDoneEvent, INFINITE);
}
// Clean up
mmres = waveOutUnprepareHeader(hwo, &whdr, sizeof(WAVEHDR));
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
waveOutSetVolume(hwo, dwOldVolume);
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
mmres = waveOutClose(hwo);
if (mmres != MMSYSERR_NOERROR) {
return mmres;
}
delete [] whdr.lpData;
waveFile.Close();
return MMSYSERR_NOERROR;
}
Take a look at the source code to understand the sound producing code clearly.
Now let’s take a look at the file operations done in the hindiengine.dll in the following diagram and the respective operations to do fread, fwrite and fseek:
[pic]
From the figure it is clear that hindiengine native code contained a number of file operations which are modified using Windows CE API functions to port it to Pocket-PC running Windows CE.
Mapping of fread, fwrite, fseek and fscanf to Windows CE API functions:
fread: It can be implemented using ReadFile.
fwrite: It can be implemented using WriteFile.
fseek: Read the file till the desired position.
fscanf: fscanf operation can be implemented by reading the file byte by byte and then putting the characters on a temporary array till the delimiter(say a blank) and then changing it to appropriate format like an integer or a string. The following code snippet retrieves token and token type from the tokens.txt file and save the token in a string and the token type in integer variable.
//Code to implement fscanf
do //Read tokens till the phrasal boundary
{
while(no_of_blanks!=2){
ReadFile(fin,&c,1,&bytesRead,NULL);
length+=1;
if(c==' ')
no_of_blanks+=1;
if(no_of_blanks==0){
token[tokencount]=c;
tokencount+=1;
}
if(no_of_blanks==1){
ttype1[ttypecount]=c;
ttypecount+=1;
}
if(length==tokenLength)
break;
}
token[tokencount]='\0';
ttype1[ttypecount]='\0';
tokencount=0;
ttypecount=0;
no_of_blanks=0;
ttype=atoi(ttype1);
} while(length !=tokenLength);
The variable token contains the token as a string and the variable ttype contains the type of the token. To read from the files like tokens.txt, intonation and epoch the above substitute of fscanf is used. To read the wav files fread and fseek are sufficient since the size of the wav file can be obtained by reading 4 bytes of the wav file after 40th byte. Thus using fseek and fread Windows CE implementation the wav files can be read from the sound file library (a directory in this implementation) and concatenated according to the ILPS algorithm to get the speech.
Please take a look at the reference section to get the algorithm used in NLP module and ILPS module.
4.1.1 Drawbacks
Take a close look at the fscanf implementation written above. The main drawback of this model is that the operations like fscanf takes time proportional to the number of characters in the file, which is not the case when fscanf is implemented using operating system directives. The file is not read byte by byte but in blocks and thus fscanf is implemented efficiently rather than reading one byte at a time. In this implementation the whole file is to be read character by character and linear scanning takes time. Also there are intonation file and epoch file which if read character by character takes high amount of time. In epoch file there is epoch value corresponding to a given token and this model linearly search for the epoch value corresponding to a given token. Linear search is expensive and therefore this is another main disadvantage of this model. Another important inference that can be made from this model is that if the token value is assumed as a key then epoch value and the sound file can be retrieved using that key value. This observation leads to the use of extendible hash based database in subsequent models. In the next model first an extendible hash based database will be explained and then the implementation of Embedded Shruti with this database will be presented.
4.2 Model 2: Windows CE port using GDBM (Without voice.db)
In Chapter 2 GNU Database manager was introduced and the reason for choosing it in place of Microsoft SQL server for CE was explained. The crude port discussed in last model has several disadvantages and in this model the linear scan required in epoch file was avoided using an extendible hash based database called GDBM. GNU Database manager was ported on Windows CE platform. Take a look at the source code of GDBMCE for details.
At this point of time it is important to understand the meaning of extendible hashing since this application needs a hash based database not a SQL supported database. Each line of the Epoch file contains the first entry as the token and it is followed by 4 different epoch values to be used in ILPS algorithm (Hindiengine module). Extendible hash based databases are very efficient when retrieval is to be done by the specified key value (in this case the token name like 0704) and the complexity of retrieval operation is O(1+alpha) where alpha is load factor which is nearly 0 for a balanced database. In this model the epoch file is read and saved in GDBM database using the token name as the key and the value being the epoch. Four epoch databases are made which contains the following:
epoch1.db ( Key is the token name and the value is the first epoch value specified on the line corresponding to that particular token name on the epoch.txt file.
epoch2.db ( Key is the token name and the value is the second epoch value specified on the line corresponding to that particular token name on the epoch.txt file.
epoch3.db ( Key is the token name and the value is the third epoch value specified on the line corresponding to that particular token name on the epoch.txt file.
epoch4.db ( Key is the token name and the value is the fourth epoch value specified on the line corresponding to that particular token name on the epoch.txt file.
For example take one line from epoch.txt file:
0165179 104 206 307 409
epoch1.db ( Key is 0165179, values is 104
epoch2.db ( Key is 0165179, values is 206
epoch3.db ( Key is 0165179, values is 307
epoch4.db ( Key is 0165179, values is 409
The present version of Embedded Shruti uses epoch1.db. For producing better quality speech later versions of the software might use the other epoch database files.
Intonation file is also saved into a GDBM database and used accordingly in the program. Thus the new model of the hindiengine can be represented by the following picture:
[pic]
Both the epoch database and the intonation database are saved on disc(secondary storage rather than main memory or RAM). The advantage is that linear scan is avoided now and the epoch can be obtained in almost O(1) time provided the key value of the epoch which is the token name.
After understanding the basic structure of this model, let’s take a detailed look on extendible hashing and why it is the most efficient data structure when a values is to retrieved according to the key value.
4.2.1 Extendible hashing
Traditional hash methods are burdened with 2 disadvantages:
• Sequential processing of a file according to the natural order on the keys is not supported.
• They are not extendible.
Hash table size is pre-determined
Hash table size heavily relies on hash function
Overestimation of the number of records results in wasted space.
Underestimation of the number of records results in rehashing
Extendible hashing method allows hashing to adapt to dynamic files. Hash tables are naturally balanced. By extending the hash address space from the directory address space, hash tables can be made extendible.
4.2.2 Extending hash tables
Assumptions:
• A hash function, h, exists.
• If K is a key, then K’ = h(K) is a pseudokey.
File is structured into two levels
• Leaves: contain (K, I(K)) (I(K) is the information associated with K)
Contains a header that stores the local depth
• Directory: the record associated with K or a pointer to the record
Contains a header that stores the depth
Contains pointers to leaf pages
Example
The following figures explain the working of extendible hash structures.
[pic]
Figure 1
[pic]
Figure 2
[pic]
Figure 3
4.2.3 Using GDBMCE library
The gdbmce.dll library exports all the functions to do the database operations. In Chapter 2 all the functions of GDBMCE was explained and all functions are ported on Windows CE platform. The .def (definition) file for the gdbmce dynamic link library exports the following functions which can be accessed by the pointers as discussed in the last model.
//GDBMCE .def file
LIBRARY GDBMCE
EXPORTS
gdbm_open
gdbm_close
gdbm_store
gdbm_fetch
gdbm_delete
gdbm_firstkey
gdbm_nextkey
gdbm_reorganize
gdbm_sync
gdbm_exists
gdbm_setopt
gdbm_errno
gdbm_version
Code snippets that are used to do the database operations using gdbmce.dll.
//Database variable
GDBM_FILE dbf;
//Variables to work with the database
datum key, content;
/*
datum is a data structure defined in gdbmce.h which has two important members. The first member of the structure is a pointer to character array while the next member of the character array is an integer which stores the number of elements in the character. Using this data structure the values are stored and retrieved from the database.
*/
//Define the function pointers to call the gdbm functions
typedef GDBM_FILE(*GDBMOpen_ptr)(WCHAR*,int,int,int,void*);
typedef void(*GDBMClose_ptr)(GDBM_FILE);
typedef int(*GDBMStore_ptr)(GDBM_FILE,datum,datum,int);
typedef datum(*GDBMFetch_ptr)(GDBM_FILE,datum);
//Instance to call the dll
HINSTANCE hInst1;
//Loading the engine dll
hInst1 = ::LoadLibrary(L"gdbmce.dll");
//Getting the function pointers of 4 GDBM functions
GDBMOpen_ptr pgdbm_open=(GDBMOpen_ptr)GetProcAddress(hInst1,L"gdbm_open");
GDBMClose_ptr pgdbm_close=(GDBMClose_ptr)GetProcAddress(hInst1,L"gdbm_close");
GDBMStore_ptr pgdbm_store=(GDBMStore_ptr)GetProcAddress(hInst1,L"gdbm_store");
GDBMFetch_ptr pgdbm_fetch=(GDBMFetch_ptr)GetProcAddress(hInst1,L"gdbm_fetch");
If the pointers (pgdbm_open. pgdbm_close, pgdbm_store, pgdbm_fetch) are NULL then the functions are not exported by the dynamic link library. It is always advisable to check whether the function pointers are NULL or not.
//Opening a database
//Database reader
dbf = (*pgdbm_open)(newstring,512,GDBM_READER,777,0);
newstring contains the name of the database to open. 512 specifies the block size in which the data will be accessed from the disc. GDBM_READER specifies that the database is to be opened in read mode. 777 defines the mode of the database file which means read, write and execute permission on the database file thus created. 0 refers to the default value that should be passed to the error function.
//Database writer
dbf = (*pgdbm_open)(newstring,512,GDBM_WRITER,777,0);
GDBM_WRITER specifies that the database is opened for writing. It also requires that the database should be present on the disc.
//Create a database
dbf = (*pgdbm_open)(newstring,512,GDBM_WRCREAT,777,0);
This will create a database if the database doesn’t exist and provide both a reader and writer for the database. *pgdbm_fetch reads the database and retrieves value corresponding to a given key value while *pgdbm_store writes into the database according to the key value thus provided.
//Storing into a database
Suppose there are two strings. The first string contains the key which is the tokenname (“0704” for example) and the second string which is epoch contains the epoch value corresponding to the key (“107” for example). Now to store the information into the database the following function will be used:
//Storing the key and its size into the datum structure
key.dptr = tokenname;
key.dsize = strlen(tokenname);
//Storing the value and its size to datum structure
content.dptr = epoch ;
content.dsize=strlen(epoch);
//Storing into the database after successful opening
(*pgdbm_store)(dbf, key, content, GDBM_INSERT);
Take a look at the GDBM_INSERT option on the function call. GDBM_INSERT parameter inserts the value corresponding to the key. If the key exists then the store operation will fail. GDBM_REPLACE is used in those cases where the key already exists and the value needs to be changed.
//Fetch pairs from the database
Suppose the epoch value corresponding to the token name (“0165179” for example) is to be fetched from a database that is opened successfully in GDBM_READ mode. The following code will be used to fetch the values:
//Storing the key and its size into the datum structure
key.dptr = tokenname;
key.dsize = strlen(tokenname);
//fetch the value corresponding to the key
content = (*pgdbm_fetch)(dbf,key);
//copy the content to a string called epoch
strcpy (epoch,content.dptr);
int epochval = atoi(epoch);
Thus as the operation completes, epochval will contain the integer value of the epoch string that is fetched from the database.
4.2.4 Advantages
Model 2 avoids linear scan of epoch file and the intonation file. Therefore this implementation is much faster and efficient compared to Model 1. A performance comparison will be given in next chapter where both the implementations are checked on some given input. For this application where pairs are to be retrieved efficiently, Extendible Hashing is the best data structure and GDBMCE uses extendible hashing.
4.2.5 Drawbacks
There are two drawbacks in this model:
1. The Tokens.txt file generated after hindianalyser phase is scanned linearly by the hindiengine dynamic link library to retrieve the token name and the token type. Refer to the implementation of fscanf using ReadFile in Model 1 section of this chapter. So in the next model to avoid this linear scan token name and token type are also saved in a GDBMCE database using an index value as key which starts from 0 and increases till there are more tokens.
2. The second drawback of this model is that the sound library is still a directory which contains the wav files. In the next model the sound files are also kept in a GDBM database as the wav files also have the token name as the key and the value is the sound file. A directory with a number of wav files are replaced by this one file called voice.db. It facilitate the transfer of this single file to the Windows CE device. Also this single file can be provided on flash ram accompanying the application. Also making the voice database will also avoid linear scanning of voice files during the generation of the speech. Since now the voice file is saved on the database as a character array, efficient array operations like memcpy can be used to avoid the linear scan of the sound files that was done in the present model.
These drawbacks resulted into the development of a third model in which the voice database is added, along with the epoch database and the intonation database that were already there. The tokens are also saved in a database and no normal file operations are used in this version. That makes the third model as the most robust model out of the other two models. Let’s now take a look at the changes done in third model.
4.3 Model 3: Windows CE port using GDBM (With voice.db)
First take a look at the new dataflow structure of Hindiengine module. The following figure displays the dataflow structure after the GDBM databases are added:
[pic]
The modifications that are made in Model 2 to obtain Model 3 were already discussed in the last section. Model 3 is the most efficient implementation so let’s take a complete pictorial view of Embedded Shruti in this implementation.
[pic]
In this implementation tokens database and voice database were added. The basic database operations that were discussed in last section will hold well in this model also.
4.3.1 Making voice database
In earlier models the sound files are saved in a directory called voice and according to the token name appropriate file is taken from the directory and appended to the existing output voice files after modifications. In this model the sound files are saved in GDBM database with key as the name of the sound file which is eventually the token name. For example if there is a file in the voice library called 0164179.wav then from this file name the token will be extracted which is filename-extension( 0164179 in this case) and the key value will be set to 0164179. After that the wav file 0164179.wav will be saved in the database with this key value. Later hindiengine will retrieve the sound file using this key value.
The database file voice.db was created on linux platform since directory scanning using system calls is quite easier in linux. GDBM is preinstalled on almost all linux platforms. A GDBM database file created on linux platform can be used in Windows CE using the GDBMCE library function calls. The following code shows how the voice database is made from the voice directory:
/* Linux code */
/* Header files needed */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
//Directory pointer to read the contents of voice directory
struct dirent *dpointer;
main()
{
//define the database handler for the music database
GDBM_FILE dbf;
//To make the music database
datum key,content;
int i=0,size;
DIR *dirp;
char *name,*buffer;
char *path;
char *voice = "voice/";
FILE* fpt;
/*
Steps by which music database will be created
1.The directory of sound files are transferred to linux machine.
2.Scan the directory,get the name of each file.
3.key = Name - trailing .wav
4.Content = The wav file.The size of the wav file can be obtained from the
file itself.The 40-44 bytes of the wav file gives the file size.
5.Accordingly the wav file will be stored by the key described above.
*/
dbf=gdbm_open("voice.db",512,GDBM_WRCREAT,777,0);
path = (char*)malloc(30*sizeof(char));
if((dirp=opendir("voice"))==NULL)
{
fprintf(stderr,"Error opening voice\n");
perror("dirlist");
exit(1);
}
//Code to scan the directory and put each wav file into database.
while(dpointer=readdir(dirp))
{
if(i>1)
{
name = strtok(dpointer->d_name,".");
//Inserting values in key
key.dptr = name;
key.dsize = strlen(name);
strcpy(path,voice);
strcat(path,name);
strcat(path,".wav");
fpt = fopen(path,"r+");
fseek(fpt,40,0);
fread(&size,4,1,fpt);
fseek(fpt,0,0);
//Add the 44 bytes of the header
size=size+44;
buffer=(char*)malloc(size*sizeof(char));
fread(buffer,size,1,fpt);
//Inserting values in content
content.dptr = buffer;
content.dsize = size;
//Inserting in database
printf("Inserting in database File no : %d\n",i);
gdbm_store(dbf1,key,content,GDBM_INSERT);
free(buffer);
fclose(fpt);
}
i++;
}
closedir(dirp);
gdbm_close(dbf1);
}
/* compile line */
bash$cc voicedb.c –o voicedb -lgdbm
/* execution */
bash$./voicedb
This will create the voice database in the present working directory. The database will be transferred to Windows CE emulator or device for use.
4.3.2 Making tokens database
To make the tokens database first of all the GDBMCE dynamic link library should be loaded into memory. After that open a database file with the name tokens.db. This file will contain the token and type for characters of the input text provided by the frontend through the file TextIscii.txt. In the database file save the token and type as they are produced by Natural Language Processor.
An index value is maintained that starts with 0 and works as a key to this database. As a new set of token and type is added to the database according to the current index, the index value is increased by 1. Hindianalyser phase returns the value of index and the frontend passes this value to Hindiengine to retrieve all the tokens and their respective type.
When the token and type are inserted in database a delimited is added between the two. The following code shows the insertion technique:
char buffer[20];
char keybuffer[20];
//0 concatenated with word[i] gives the token name.
//1 is the token type in this case.
//delimiter | is added between the token name and type.
sprintf(buffer,"%d%d|%d",0,word[i],1);
//content is the datum variable needed for insertion
content.dptr = buffer;
content.dsize = strlen(buffer);
//key is the datum variable to hold the key which is index in this case
sprintf(keybuffer,"%d",index);
key.dptr = keybuffer;
key.dsize = strlen(keybuffer);
//dbftokens is the handler to the tokens database
//Function is called with GDBM_REPLACE as the argument so that the //database will be rewritten if the key already exists.
(*pgdbm_store)(dbftokens,key,content,GDBM_REPLACE);
//increase the index value
index = index + 1;
4.3.3 Producing the output sound file
Hindiengine will first get the token name and token type from tokens database. Once the token name is obtained, it is used as a key to retrieve the sound file from the voice database. The following code shows the whole process:
//Fill the key to retrieve content from the database
sprintf(tokenbuffer,"%d",index);
tokenskey.dptr = tokenbuffer;
tokenskey.dsize = strlen(tokenbuffer);
tokenscontent = (*pgdbm_fetch)(dbftokens,tokenskey);
//Get the token and the type from tokenscontent.
token = strtok(tokenscontent.dptr,"|");
ttype1 = strtok(NULL,"|");
ttype = atoi(ttype1);
//This code finds the length of the voice file and copies the header of //the wav file into an variable Header which will later be added to the //output sound file. In wav files 4 bytes after 40 bytes gives the size //of the file.
voicekey.dptr = token;
voicekey.dsize = strlen(token);
voicecontent = (*pgdbm_fetch)(dbfvoice,voicekey);
memcpy(Header,&voicecontent.dptr[0],40);
len = (voicecontent.dsize-44);
//This code copies the remaining wav file (except the first 44 bytes of //the header) into a temporary character array called data and it will //be concatenated to the output sound file later.
memcpy(data,&voicecontent.dptr[44],len);
This completes the description of model 3.
4.3.4 Advantages
This model is the most efficient model compared to other two models discussed above. Linear scans of the files are completely avoided and memory efficient functions like memcpy are used to increase the performance of the software. As all databases are kept on the disc, this model gives an upper bound on the performance. No efficient performance that always access disc rather than main memory cannot take time less than this implementation. No file operations are used in this implementation and therefore this is a robust implementation.
4.3.5 Drawbacks
This model also has the following drawbacks:
1. The tokens database is saved on disc rather than in main memory. So both in Hindianalyser and Hindiengine modules, to write the tokens and then again to read the tokens disc access is needed which takes more time compared to RAM access. A solution to this problem is to maintain the list of tokens in main memory rather writing it in database in disc. Another solution will be to maintain the tokens database in a Flash RAM rather than on the secondary storage which is the disc. Flash RAM access time is much less compared to disc access time.
2. Whenever a sound file is retrieved from the database disc is accessed since the voice database is saved on disc. This will take more time and affect the performance of the software.
These drawbacks lead to the development of Model 4 in which both these problems are addressed and possible solutions are suggested. The next section will explain the solutions that will increase the efficiency by removing the drawbacks of Model 3.
4.4 Model 4: Final Windows CE port
Model 4 is a hybrid model which judiciously uses main memory and secondary storage (disc) to obtain the optimal performance. Model 3 if implemented on a Flash RAM will give better performance but still the performance can be enhanced by using this hybrid approach.
4.4.1 Approach
This model does two important additions to the last model and attempts to increase the performance. The additions are the following:
1. The token list which was stored on the disc in last model will be stored in main memory so that the access will take less time. Since Embedded Shruti is built on Microsoft Foundation Classes for Windows CE, a number of MFC utility classes can be used to maintain a hash structure of the tokens. The hash facilitates retrieval. In this implementation a MFC class CMap is used to store the token name and the token type keyed by a variable index which is increased accordingly.
2. The other problem in model 3 was that each time a new sound file is accessed from the database, disc access time is needed. A cache structure is implemented to speed up sound file access. The cache structure stores N number of sound files on the main memory. N is selected according to the application. Typically N can be 20 sound files. When a new file is required first of all the cache is checked whether the file is there in the cache or not. If the file is available then the disc access time is not required. If the file is not available the file is brought from the database on disc and it will be saved in the cache. If the cache is full then an appropriate cache replacement strategy like Least Recently Used Algorithm (LRU) is used. The victim sound file will be chosen and removed from the cache. In its place the new sound file will be kept.
The modifications suggested will optimally use the Random Access Memory and the secondary disc so that Embedded Shruti gives the ideal performance. Till now the models are tested on Pocket-PC emulator and as mentioned in the API reference of the Pocket-PC, the performance of the software on real Pocket-PC will be better than the performance on the emulator.
This chapter will conclude with a graphical view of the model 4. The next chapter will give the performance comparison of different models on some input string. Since the input string remains same the time taken by different models will clearly differentiate between the performances of the implementations.
4.4.2 Dataflow Model
[pic]
Chapter 5
Performance Comparison
In the last chapter different models for Embedded Shruti were discussed at length. This chapter will present the performance of each model on a given input text. This chapter will also specify the steps to run different models of Embedded Shruti on Pocket-PC emulator. Performance comparison is an important part of the development process since this phase determines which model scores over the others and therefore should be chosen as the final implementation that will be ported.
5.1 Performance Parameters
First of all the performance parameters are to be specified. For real time applications the performance should be measured on the basis of actual time taken. Windows CE is a real time operating system and therefore softwares running on real time applications. To measure the performance real time should be considered. For different models the time to get the output once the input text is supplied and the Analyse and Generate buttons are clicked will be considered. The model which scores better over others on this metric will be considered as the better implementation. There may be several other parameters like RAM space used and Disc space used but they are not of much interest. For Embedded Applications real time constraints should be satisfied. So the time taken for the application to execute is the most important performance parameter.
5.2 Simulations on test inputs
This section will explain how to run each model on Pocket-PC emulator and then to check the program on given test inputs. For every implementation the steps will be provided to run the application.
5.2.1 Model 1
For running the application on Model 1 the following steps should be done:
1. First of all compile the source code. The source code includes the source code for Frontend, and the source for the two dynamic link libraries Hindianalyser and Hindiengine. All the three modules will be compiled using the eMbedded Visual C++.
2. On the eMbedded Visual C++ IDE, specify the SDK as the Pocket-PC, and the next fields as Win32 (WCE x86 debug) and Pocket PC 2002 emulation.
3. If the compilation is successful, then the dynamic link libraries will be made and transferred into the Pocket-PC emulator.
4. The executable Frontend.exe will also be made and transferred into the Pocket PC’s default executable path.
5. The dynamic link libraries are copied into \Windows directory on the target emulator or the target device. An MFC dll is also copied to \Windows directory as MFC dll is needed to run the Frontend executable
6. Now before running the application upload the files epoch.txt and inton_bengali onto the emulator. To upload the files go to Tools ( Remote File Viewer. Once the Remote File Viewer appears the files can be transferred onto the emulator or the device.
7. After the files are transferred the next step is to transfer the sound library on the emulator or target device. A new directory will be made called voice on the device and then using Remote File Viewer the wav files will be uploaded into the voice directory.
8. The application can be run by clicking on Frontend.exe on the start menu. The Frontend GUI will start and the Bengali text for Text-to-Speech conversion will be applied to it.
9. An example of a Bengali or Hindi Text can be “mera naam piyush hai”. This text will be entered in input area and then performance will be obtained by pressing the Analyse button and the Generate button.
10. A sound file will be generated as the output and will be played on the emulator or the device.
11. The next section will compare the real time performance of this model with other models.
5.2.2 Model 2
1. In this model GDBMCE library is used. Therefore first of all source code for GDBMCE library will be compiled.
2. Successful compilation will upload the gdbmce.dll to \Windows folder on the target device or the emulator.
3. epoch.txt and inton_bengali files will not be transferred to the device. Instead the hash database epoch1.db and inton_bengali.db will be transferred to the device.
4. Remaining all steps will be same as done in Model 1.
5.2.3 Model 3
1. This model don’t require the sound library (the folder consisting of wav files) to be transferred on the device. Instead in this model the voice database (voice.db) is transferred to the device.
2. Rest all steps remains same as Model 2.
5.3 Comparison of performance
The following table gives the performance of each model according to the time taken by the Hindianalyser module (clicking on the Analyse Button) and the time taken by the Hindiengine module (clicking on the Generate Button). The input text used for the
Comparison: “mera naam piyush hai”
|Model Name | Hindianalyser Performance | Hindiengine Performance |
| | | |
|Model 1 |4 seconds |70 seconds |
| |(Tokens in file) |(Very inefficient) |
| | | |
|Model 2 |4 seconds |10 seconds |
| |(Tokens in file) |(Increase in efficiency) |
| | | |
|Model 3 |4 seconds |5 seconds |
| |(Token database added) |(Best performance) |
On the basis of this performance chart it can be concluded that Model 3 is the most efficient one and this is to be used for the final implementation. Model 4 is also suggested which is an extension of this model 3 and use a hybrid approach as discussed in the last chapter.
Chapter 6
Conclusions
This thesis provides the complete design and implementation of Embedded Shruti. It started with an introduction to technologies that were used in this software product. After that details of different models were provided. The last chapter provides a comparison of the performance of different models and the reason for choosing Model 3 as the final implementation.
Embedded Shruti has several advantages over the desktop version. To run the desktop version one need a desktop computer system that is costly compared to a Personal Digital Assistant like Pocket-PC. Pocket-PC is a mobile device and therefore the software can be used on the move by the user. A person with speech disorders only have to carry a PDA with Embedded Shruti installed on it. The person can communicate with others using the software and since it is installed on a PDA rather than a desktop computer he can take the software with him at any place.
I personally feel that Embedded Shruti realizes the dream of providing Shruti software to every person who needs it. For a person with speech disorders this software will be an integral part of life. Carry a Personal Digital Assistant having Embedded Shruti and you have the power to communicate with people despite your serious speech disorders.
Chapter 7
Future Work
Embedded Shruti is to be tested completely on a number of variable length test inputs. Hindianalyser module is tested completely but Hindiengine module is not rigorously tested. The software is giving perfect results for the input strings on which it is tested till now but still more testing is required.
The final version which is to be shipped to customers will save the voice database, intonation database and epoch database on a Flash rather than on the secondary storage of the Pocket-PC device. Flash comparatively takes less time than disc and so it will surely increase the performance. A Flash version of the code is to be written. In the Flash version of the code, the path of the database has to be changed. Presently since the database is on the root directory of Pocket-PC, the path is simply the name of the database like “voice.db”. For example when the database is opened, the path of the database is “voice.db”. But when a Flash will be connected to the device the path will change to “\Storage Card\voice.db”. In the Flash version of the code this change will be incorporated.
The software is tested on Pocket-PC emulator till now. Once the testing and debugging is done it will be ported on Pocket-PC hardware. The databases, the dynamic link libraries (hindianalyser, hindiengine and gdbmce) and the application Frontend.exe will be transferred to the device using eMbedded Visual C++. The environment is changed to Pocket-PC (default device) from Pocket-PC (Emulation) and the device will be connected to the development workstation using some COM port. After that the files can be transferred to Pocket-PC.
Chapter 8
Software Screenshots
8.1 Hindianalyser module on Standard SDK emulator (First port)
[pic]
[pic]
The output of Hindianalyser module is shown in the second text box. 0204 is the token and 0 is the token type. The output has repetitive sequence of token and token type.
8.2 Model 1 on Pocket-PC Emulator
8.2.1 Hindianalyser module execution: The text box contains the token and token type generated in this phase. The pairs generated are:
0204 0 0204172 3 0172 1 0172207 2 0207 0 -2 5 0198 0 0198164 3 0164 1 0164164 4 0164 1 0164204 2 0204 0 -2 5 0200 0 0200166 3 0166 1 -1 5 0205 0 0205168 3 0168 1 0168213 2 0213 0 -2 5 0216 0 0216173 3 0173 1 -2 5
[pic]
8.2.2 Hindiengine Module execution: After the Analyse button is clicked the tokens are generated and displayed on the second text box. This completes the execution of Hindianalyser module. Hindiengine module is called when Generate button is clicked. After Generate is clicked the speech file will be generated and played. The second text box will be updated by the number of bytes in the tokens.txt file.
[pic]
8.3 Model 3 on Pocket-PC emulator: Model 1 screenshots are shown above. Please refer chapter 4 for knowing in details about the models. Model 3 is implemented using only Hash databases and no file operations are used. This model works efficiently as compared to the other two models. Refer next page for Model 3 screenshots.
8.3.1 Hindianalyser module execution: In Model 3 before executing the Frontend, database files will be sent to the device. The database files are: inton_bengali.db (intonation database), epoch.db (epoch values) and the voice database (voice.db). This model gives the best performance as shown in Chapter 6.
[pic]
8.3.2 Hindiengine Module execution: The next screenshot shows the application after the Hindiengine module is executed by clicking on Generate button. It plays the sound and gives the output as the total number of pairs in the tokens database.
[pic]
The number of < token, token type> pairs generated from the input text is shown at the text box. The Hindiengine model execution is efficient compared to Model 1 and Model 2. Therefore this Model emerges as the winner and it will be used in the final version of Embedded Shruti.
Chapter 9
References
Embedded Shruti is an implementation project. The documentations which helped me in this project are listed chapter wise:
Chapter 1
None
Chapter 2
1. Programming Microsoft Windows CE (Second Edition) by Douglas Boling
2. Windows CE .NET documentation.
3. Pocket-PC SDK documentation.
4. Microsoft eMbedded Visual C++ documentation.
5. Microsoft SQL Server CE documentation.
6. GDBM man pages
Chapter 3
1. Choudhury M. Rule-based Grapheme to Phoneme Mapping for Hindi Speech Synthesis. Presented at the 90th Indian Science Congress of ISCA, Bangalore, 2003
2. Source code of Desktop version of Shruti
Chapter 4
1. GDBM man pages.
2. Source code of GDBM port to Windows CE.
3. Ronald Fagin, Jrg Nievergelt, Nicholas Pippenger, H. Raymond Strong, Extendible hashing - a fast access method for dynamic files, ACM Transactions on Database Systems, New York, NY, Volume 4 Number 3, 1979, pages 315-344.
The complete source code of the implementation is available in MediaLab, Indian Institute of Technology, Kharagpur. Take a look at the source code to understand how the software is working. All the models are implemented separately and you can yourself do a performance evaluation of the respective models.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.