Introduction
Low Level Functions used
Sockets
Other Topics
Introduction
The code for this application and its interface was written in C using the Low Level API Functions for indepth functionality.
Supplied library functions, as part of the Windows package, enable developers to develop for any hardware device without having intimate knowledge of device dependent information. The Microsoft library MMSYSTEM.LIB, or multimedia system, provides all of the required functionality for multimedia development. In this library, Microsoft provides development functionality for two different types of multimedia programming services, high level and low level.
High level services enable the developer to play and record audio sound with ease, often only requiring one function call. These high level services are very easy to implement, and require less programming than the available low level options. With the high level services, the developer can start and stop recording and playback, but there is little control available beyond that. If the developer wants to get his hands dirty, and get into the intricate details of record and playback, then they must find another way. If simple record and playback are all that is necessary for your application, then the high level services will meet the requirements of most applications.
Occasionally, the high level services do not meet the requirements of a specific application. For these special purpose audio requirements, the option available to the software engineer is to use the low level services. These low level functions provide the developer with a device independent interface to audio hardware. The low level services allow the developer to communicate more directly with the audio device drivers. This enables greater control and flexibility for the programmer to manage audio playback and recording. These low level services are more complex, and require a greater knowledge of the multimedia library, and more programming than the high level services, but the trade off is greater control of the audio device and of record and playback functions.
With these services, a developer can query audio devices, open and close the device drivers, prepare and manage audio data, and handle errors.
There are many initial preparation steps that must be taken in a program before actual recording and playback can be accomplished. First, a developer must ensure that the computer can perform the required functions. Since Windows uses a generalized interface when interacting with all external devices, there has to be a way for the developer to determine if the specific device in the machine running the application meets the program's minimum requirements. It must be verified that the computer has the needed audio devices, and that these devices support the format that it is being asked to handle. Because you have no way of knowing whether the sound device is the latest technology or the oldest piece of junk, the device must be tested ahead of time to ensure that it will perform. Microsoft provides functionality to test a system for specific audio devices, and once it is determined that the devices of the certain type are present, test the capabilities of the devices present for the required format.
To determine the number of output and input devices of a certain type available in a given system, the following functions are used:
waveInGetNumDevs
waveOutGetNumDevs
These functions query the system for the number of waveform input and output devices respectively, and return the counts for the devices present.
Once it is verified that the required devices are present in the system, it is necessary to query for the capabilities of each device, to ensure that it supports the required form. To accomplish this task, the following functions are called:
waveInGetDevCaps
waveOutGetDevCaps
Each of these functions will fill a supplied data structure with the information on the capabilities of the specified device. After a data block has been allocated, and it is ready to be sent to the device, it must be prepared for use. After this block has been filled or played, and the device is finished with it, the preparation performed on this block must be cleaned up, and the data block must be unprepared. The following functions are used:
waveInPrepareHeader
waveInUnprepareHeader
waveOutPrepareHeader
waveOutUnprepareHeader
These functions complete the preparation and clean up needed for both wave input and output, and constitute just one more step toward the desired goal of recording and playback. In order to interact with the audio device and perform audio services, the hardware device must be prepared. Since audio devices are usually not shareable, we must open it and request its services. If the device is already in use, an error will be returned. When we are done with the device we should immediately close it to make it available for other requests. In our case, we need the device for both output and input, so once we are done with wave output, we need to immediately make a request for record, and the device must be opened for wave input. The following functions perform the tasks of opening and closing hardware devices:
waveInOpen
waveInClose
waveOutOpen
waveOutClose
They make requests for service, and when done with the hardware, release the device so that other requests can be serviced.
In order to record or play a sound sample, we must know the capabilities of the device that we are using to ensure that it meets our requirements. These data structures WAVEOUTCAPS, and WAVEINCAPS that we pass as arguments to function calls, return the desired information about device capabilities.
For recording and playback, the WAVE input and output devices must be opened. When we open this device, we must give the device certain information about how we want to record or playback. We pass a data structure, WAVEFORMAT structure, that identifies the desired format for recording/playing the sound samples data.
A callback function can be specified in the waveInOpen () function when the waveform audio input device is opened. This callback function receives messages to indicate the progress of the device. This application specifies a WaveInProc () function, to be used as the callback function. The use of the callback WIM_DATA message notifies the application that a datablock has been filled with recorded audio and requires processing. This is setup to monitor the datablocks received from the waveform audio input device and pass them on to the main WndProc() procedure.
The header WAVEHDR is used to describe the data block. Every sample sent to a device for playback, as well as every empty block sent to be filled with a sample, has a WAVEHDR associated with it. This data structure, is used to both give information to the device, as well as get information back about the sound sample data. This structure is used to tell the device where to store samples, the length of the samples, as well as assorted information about the data playback.
When the WAVEHDR is returned to the application after the device is finished with the data block, it contains some information about the sample for the user. If the buffer was used for recording, the header contains information about the number of bytes recorded. A flag is also set by the device to signal that it is finished with the data buffer, and has returned it to the application.
This project required the use of network services in order to allow the software to communicate from one computer to another. Once a sound sample is recorded on a local machine, that sample must then be delivered to the remote system for playback, thus enabling two way communication, and simulation of a telephone on a computer. After the sample has been processed, it must be packaged according to certain standards, addressed to the correct machine, and then be released on a network wire to be transported to the remote system.
Our project was designed to interface with networks. The protocol that is commonly used on the network is TCP\IP. This protocol consists of a set of standards that must be met in order for different computers to communicate, and each understands what the other is saying. This is a set of standards that defines how information is packaged, addressed and transmitted across a network. The data that you send is broken up into chunks called 'packets'. These packets must be addressed correctly or they will never reach their destination.
On a network, each machine is uniquely identified by a name, as well as an IP address or Internet Protocol address. This address consists of four numbers, such as 1.2.3.4. This information is used to identify the network number and host number on that network. It is the IP address that is used to route packets from the sender to the appropriate destination machine. In order for a machine to receive the information that was sent to it, you must specify the IP address.
The basic network interface is the Socket. This is the end point of communication for network applications. This is a simple interface that allows easy development of network programs. The socket is an end point of communication that allow applications to "plug in" to the network. The socket concept is supported by a library that contains all the function calls required for any network programming. When an application requires network services, it calls procedures from the set of library calls in order to conduct network activity.
There are two types of sockets available that will be of immediate concern to us, stream and datagram. Stream sockets use TCP, while datagram sockets use UDP. TCP was designed for reliable, error free data transfer. This provides a connection between hosts, and allows error detection, packet ordering, and retransmission for lost packets. Before a packet is sent, a connection is established between computers, and every packet sent is checked to ensure that it has no errors, and arrives in the proper sequence. If there are any errors, TCP corrects them automatically. With all of these checks on packet transmission, TCP can be relatively slow. If no guarantees are required for packet transmission, and if speed is more important than accuracy, then TCP is not the way to go. UDP does not require a connection between hosts, and has little error checking. Packets are simply sent on the wire, and can travel any data path to the destination. When a packet is sent, very little error checking is performed, and there is no way to determine if the packets arrived in the correct order, or if they arrived at all. Although this is very unreliable, this leads to faster data transfer.
In UDP, there is no time wasted for a connection to be established, or error checking to be performed. Although there are no guarantees that data will arrive, for our specific needs UDP was chosen as the transmission protocol. We created a near real time voice application. It was determined that speed was the highest priority, and since the data transmitted was sound samples, we could afford to loose a small percentage of packets without adversely affecting the quality.
The Windows Sockets Specification was developed in order to create a standard socket interface. This led to the creation of the Windows Socket, or WINSOCK.DLL for Windows based PCs. Each vendor's version may be different in terms of how it is implemented, but once it is configured properly each .DLL should have the same functions. This enabled developers to create applications that interface with any of the available Winsock Compliant Sockets, without requiring vendor specific implementation knowledge. This generic interface allows a developer to create an application that will run on top of any standard WINSOCK.DLL from any vendor.
WINSOCK.DLL actually acts as a "layer" between Winsock applications and TCP/IP stacks. Applications needing network services call procedures from the set of standard Winsock library calls, and these procedures call procedures in the drivers supplied by the individual vendors. Applications tell WINSOCK.DLL what to do, and WINSOCK.DLL translates these commands for the vendor stacks, and these drivers then communicate with the computer's network interface card (NIC).
MAIN PAGE
INTRODUCTION TO THE APPLICATION
ABOUT THE APPLICATION
ALGORITHM
MINIMUM SYSTEM REQUIREMENTS
UPGRADATION POSSIBLE
DEVELOPED BY
VIEW AND DOWNLOAD THE SOURCE CODE