Real Time Data Transmission Using UDP

Contents
1.Introduction 2.Audio Programming 2.1 Introduction 2.2 General Programming Guidelines 2.3 Simple Audio Programming 2.3.1 Declarations for an Audio Program 2.3.2 Definitions for an Audio Program 2.3.3 Selecting and Opening the Sound Device 2.3.4 Opening a Device File 2.3.5 A Simple Recording Application 2.3.6 Simple Playback Application 2.3.6.1 Selecting Audio Format 2.3.6.2 Selecting the Number of Channels (Mono/Stereo) 2.3.6.3 Selecting Sampling Rate (speed) 2.3.7Interpreting Audio Data 2.3.7.1 8-bit Unsigned 2.3.7.2 16-bit Signed 2.3.7.3 24 and 32 bit signet formats 2.3.8 Encoding of Stereo Data 2.3.8.1 Multiple channels 2.3.8.2 Interleaved multi channel audio 2.3.8.3 Multiple audio device method 2.3.8.4 Mixed multi device and interleaved method 2.3.9 Changing mixer settings for an audio device 3.The Data Encryption Standard (DES) 3.1 Introduction 3.2 Encryption and decryption scheme 3.3 The Strength of DES

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

4.User Datagram Protocol (UDP) 4.1 Introduction 4.2 Header Format 4.3 Applications of UDP 4.4 Programming of UDP (socket programming) Conclusion References

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

1.INTRODUCTION

The project deals with real time data transmission using UDP.The data chosen is voice.

The following figure represents the block diagram.The block diagram is broadly divided into,
Tramsmitter (client) Receiver (server)

Transmitter: In this the first block represents the Microphone through which the voice is been transmitted to Codec , where the voice signal is been encoded into digital data that further encrypted and transmitted using User Datagram Protocol (UDP) socket. Receiver: In this the encrypted (cipher text) data is received at receiver socket and is given to decryption block where we get the decrypted data (plain text). Which further given to codec, where decoding is been done. The analog output is fed to the player, where the original voice signal is listened.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

2.Audio Programming
2.1 Introduction Digital audio is the most common method used to represent sound inside a computer. In this method, sound is stored as a sequence of samples taken from an audio signal at constant time intervals. A sample represents the volume of the signal at the moment when it was measured. In uncompressed digital audio, each sample requires one or more bytes of storage. The number of bytes required depends on the number of channels (mono, stereo) and sample format (8 or 16 bits, mu-Law, etc.). The time interval between samples determines the sampling rate, usually expressed in samples per second or Hertz. Commonly used sampling rates range from 8 kHz (telephone quality) to 48 kHz (DAT tape). With the latest professional devices you can get as high as 96 kHz (DVD audio). The physical devices used in digital audio are known as an ADC (Analog to Digital Converter) and DAC (Digital to Analog Converter). A device containing both ADC and DAC is commonly known as a codec. The codec device used in SoundBlaster cards is often referred to as a DSP or Digital Signal Processor. Strictly speaking, this term is incorrect since true DSPs are powerful processor chips designed for signal processing applications rather than just a codec. The sampling parameters affect the quality of the sound which can be reproduced from the recorded signal. The most fundamental parameter is the sampling rate which limits the highest frequency than can be stored. Nyquist's Sampling Theorem states that the highest frequency that can be reproduced from a sampled signal is at most half of the sampling frequency. For example, an 8 kHz sampling rate permits recording of signals in which the highest frequency is less than 4 kHz. Higher frequency signals must be filtered out before feeding them to a DAC. The encoding format (or sample size) limits the dynamic range of the recorded signal (the difference between the faintest and the loudest

C-DAC,Hyderabad

Real Time Data Transmission Using UDP signal that can be recorded). Theoretically the maximum dynamic range of a signal is 6 dB for each bit of sample size. This means, for example, that an 8-bit sample size gives dynamic range of 48 dB while 16-bit resolution can achieve 96 dB. There is a tradeoff with sound quality. The number of bytes required to store an audio sequence depends on the sampling rate, number of channels, and sampling resolution. For example, storing one second of sound with one channel at an 8 kHz sample rate and 8-bit sample size take 8000 bytes of memory. This requires a data rate of 64 kbps, equivalent to one ISDN B channel. The same sound stored as 16-bit 48 kHz stereo samples takes 192 kilobytes. This is a 1.5 Mbps data rate, roughly equivalent to a T1 or ISDN primary rate interface. Looking at it another way, at the higher data rate 1 megabyte of memory can store just 5.46 seconds of sound. With 8 kHz, 8-bit sampling the same megabyte of memory can hold 131 seconds of sound. It is possible to reduce memory and communication costs by compressing the recorded signal but this is beyond the scope of this document. OSS provides three kinds of device files for audio programming. The only difference between the devices is the default sample encoding used after opening the device. The /dev/dsp device uses 8-bit unsigned encoding while /dev/dspW uses 16-bit signed little-endian (Intel) encoding and /dev/audio uses logarithmic mu-law encoding. There are no other differences between the devices. All of them work in 8 kHz mono mode after opening them. It is possible to change sample encoding by using ioctl calls, after which all of the device files behave in a similar way. However, it is recommended that the device file be selected based on the encoding to be used. This gives the user more flexibility in establishing symbolic links for these devices. In short, it is possible to record from these devices using the normal open, close, read and write system calls. The default parameters of the device files (discussed above) have been selected so

C-DAC,Hyderabad

Real Time Data Transmission Using UDP that it is possible to record and play back speech and other signals with relatively low quality requirements. It is possible to change many parameters of the devices by calling the ioctl functions defined later. All codec devices have the capability to record or playback audio. However, there are devices which don't have recording capability at all. Most audio devices have the capability of working in half duplex mode which means that they can record and play back but not at the same time. Devices having simultaneous recording and playback capability are called full duplex. The simplest way to record audio data is to use standard UNIX commands such as cat and dd. For example "cat /dev/dsp >xyz" records data from the audio device to a disk file called xyz until the command is killed (e.g. with Ctrl-C). The command "cat xyz >/dev/dsp" can be used to play back the recorded sound file (note that you may need to change the recording source and level using a mixer program before recording to disk works properly). Audio devices are always opened exclusively. If another program tries to open the device when it is already open, the driver returns immediately with an error (EBUSY). 2.2 General Programming Guidelines: It is highly recommended that you carefully read the following notes and also the Programming Guidelines chapter of the Introduction section. These notes are likely to prevent you from making the most common mistakes with the OSS API. At the very least you should read them if you have problems in getting your program to work. This section lists a number of things that must be taken into account before starting programming digital audio. Many of the features referred to in these notes will be explained in more detail later in this document.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP Avoid extra features and tricks. They don't necessarily make your program better but may make it incompatible with future devices or changes to OSS. Open the device files using O_RDONLY or O_WRONLY flags whenever it is possible. The driver uses this information when making many optimizing decisions. Use O_RDWR only when writing a program which is going to both record and play back digital audio. Even in this case, try to find if it is possible to close and reopen the device when switching between recording and playback. Beware of byte order (endian convention) issues with encoding of 16-bit data. This is not a problem when using 8-bit data or normal 16-bit sound cards in little-endian (Intel) machines. However, byte order is likely to cause problems in big-endian machines (68k, PowerPC, SPARC, etc.). You should not blindly try to access 16-bit samples as signed short. The default recording source and recording level are undefined when an audio device is opened. You should inform the user about this and instruct them to use a mixer program to change these settings. It is possible to include mixer features in a program which works with digital audio, but it is not recommended since it is likely to make your program more hardware dependent. Mixers operate differently and in fact may not be present at all. Explicitly set all parameters your program depends on. There are default values for all parameters but it is possible that some future devices may not support them. For example, the default sampling speed (8 kHz) or sampling resolution (8-bit) may not be supported by some high end professional devices. Always check if an error code (-1) is returned from a system call such as ioctl. This indicates that the driver was not able to execute the request made by your program.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP In most cases ioctl modifies the value passed in as an argument. It is important to check this value since it indicates the value that was actually accepted by the device. For example, if the program requests a higher sampling rate than is supported by the device, the driver automatically uses the highest possible speed. The value actually used is returned as the new value of the argument. As well, the device may not support all possible sampling rates but in fact just a few of them. In this case the driver uses the supported sampling rate that is closest to the requested one. Set sampling parameters always so that number of channels (mono/stereo) is set before selecting sampling rate (speed). Failing to do this will make your program incompatible with cards such as the SoundBlaster Pro which supports 44.1 kHz in mono but just 22.05 kHz in stereo. A program which selects 44.1 kHz speed and then sets the device to stereo mode will incorrectly believe that the device is still in 44.1 kHz mode when actually the speed is decreased to 22.05 kHz. If examining an older program as an example, make sure that it follows these rules and that it actually works. Many old programs were made for early prototype versions of the driver and they are not compatible with later versions (2.0 or later). Avoid writing programs which work only in 16-bit mode since some audio devices don't support anything other than 8-bit mode. It is relatively easy to write programs so that they are capable of output both in 8 and 16-bit modes. This makes the program usable for other than 16-bit sound card owners. At least you should check that the device supports 16-bit mode before trying to output 16-bit data to it. 16-bit data played in 8-bit mode (and vice versa) just produces a loud annoying noise. Don't try to use full duplex audio before checking that the device actually supports full duplex mode.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP Always read and write full samples. For example, in 16-bit stereo mode each sample is 4 bytes long (two 16-bit sub-samples). In this case the program must always read and write multiples of 4 bytes. Failing to do so will cause lost sync between the program and the device sooner or later. In this case the output and input will be just noise or the left and right channels will be reversed. Avoid writing programs which keep audio devices open when they are not required. This prevents other programs from using the device. Implement interactive programs so that the device is opened only when user activates recording and/or playback or when the program needs to validate sampling parameters (in this case it should handle EBUSY situations intelligently). However, the device can be kept open when it is necessary to prevent other programs from accessing the device. Always check for and display error codes returned by calls to the driver. This can be done using perror, strerror or some other standard method which interprets the error code returned in errno. Failing to do this makes it very difficult for the end user to diagnose problems with your program. 2.3 Simple Audio Programming: For simplicity, recording and playback will be described separately. It is possible to write programs which record and play back audio simultaneously but the techniques for doing this are more complex and so will be covered in a later section. 2.3.1 Declarations for an Audio Program All programs using the OSS API should include <soundcard.h> which is a C language header file containing the definitions for the API. The other header files to be included are <ioctl.h>, <unistd.h> and <fcntl.h>. Other mandatory declarations for an audio application are a file descriptor for the device file and a program buffer which is used to store the audio data during processing by the program.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP The following is an example of declarations for a simple audio program: /* * Standard includes */ #include <ioctl.h> #include <unistd.h> #include <fcntl.h> #include <sys/soundcard.h> /* * Mandatory variables. */ #define BUF_SIZE 4096 int audio_fd; unsigned char audio_buffer[BUF_SIZE]; 2.3.2 Definitions for an Audio Program In the above, the BUF_SIZE macro is used to define size of the buffer allocated for audio data. It is possible to reduce the system call overhead by passing more data in each read and write call. However, shorter buffers give better results when recording. The effect of buffer size will be covered in detail in the section Improving Real Time Performance. Buffer sizes between 1024 and 4096 are good choices for normal use. 2.3.3 Selecting and Opening the Sound Device An audio device must be opened before it can be used. As mentioned earlier, there are three possible device files which differ only in the default sample encoding format they use (/dev/dsp used 8-bit unsigned, /dev/dspW uses 16-bit signed little-endian and /dev/audio uses mu-law). It is important to open the right device if the program doesn't set the encoding format explicitly. The device files mentioned above are actually just symbolic links to the actual device files. For example, /dev/dsp normally points to / dev/dsp0, which is the first audio device detected on the system. The user

C-DAC,Hyderabad

Real Time Data Transmission Using UDP has the freedom to set the symbolic links to point to other devices if it produces better results. It is good practice to always uses the symbolic link name (e.g. /dev/dsp) and not the actual device name (e.g. /dev/dsp0). Programs should access the actual device files only if the device name is made easily configurable. It is recommended that the device file is opened in read only (O_RDONLY) or write only (O_WRONLY) mode. Read write mode (O_RDWR) should be used only when it is necessary to record and play back at the same time (full duplex mode). The following code fragment can be used to open the selected device defined as DEVICE_NAME). The value of open_mode should be O_WRONLY, O_RDONLY or O_RDWR. Other flags are undefined and must not be used with audio devices. 2.3.4 Opening a Device File if ((audio_fd = open(DEVICE_NAME, open_mode, 0)) == -1) { /* Open of device failed */ perror(DEVICE_NAME); exit(1); } int len; if ((len = read(audio_fd, audio_buffer, count)) == -1) { perror("audio read"); exit(1); } It is recommended that programs display the error message returned by open using standard methods such as perror or strerror. This information is likely to be very important to the user or support group trying to determine why the device cannot be opened. There is no need to handle the various error messages differently. Only EBUSY (Device busy) can be handled by the program by trying to open the device again after some time (although it is not guaranteed that the device will ever become available).

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

2.3.5 A Simple Recording Application Writing an application which reads from an audio device is very easy when the recording speed is relatively low, the program doesn't perform time consuming computations, there are no strict real-time response requirements. Solutions to handle exceptions to this case will be presented later in this document. All the program needs to do is to read data from the device and to process or store it in some way. The following code fragment can be used to read data from the device: Sound Recording In the above example, variable count defines the number of bytes the program wants to read from the device. It must be less or equal to the size of audio_buffer. In addition, it must always be an integer multiple of the sample size. Using an integer power of 2 (i.e. 4, 8, 16, 32, etc.) is recommended as this works best with the buffering used internally by the driver. The number of bytes recorded from the device can be used to measure time precisely. The audio data rate (bytes per second) depends on sampling speed, sample size and number of channels. For example, when using 8 kHz 16-bit stereo sampling the data rate is 8000 * 2 * 2 = 32000 bytes/second. This is actually the only way to know when to stop recording. It is important to notice that there is no end of file condition defined for audio devices. An error returned by read usually means that there is a (most likely permanent) hardware error or that the program has tried to do something which is not possible. In general it is not possible to recover from errors by trying again, although closing and reopening the device may help in some cases. 2.3.6 Simple Playback Application A simple playback program works exactly like a recording program. The only difference is that a playback program calls write.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP NOTE It is important to always set these parameters in the above order. Setting sampling rate before the number of channels doesn't work with all devices. Setting Sampling Parameters There are three parameters which affect the sound quality (and therefore memory and bandwidth requirements) of sampled audio data. These are: & sample format (sometimes called as number of bits), & number of channels (mono or stereo), and & sampling rate (speed). It is possible to change sampling parameters only between open and the first read, write or other ioctl call made to the device. The effect of changing sampling parameters when the device is active is undefined. The device must be reset using the ioctl SNDCTL_DSP_RESET before it can accept new sampling parameters. 2.3.6.1 Selecting Audio Format Sample format is an important parameter which affects the quality of audio data. The OSS API supports several different sample formats but most devices support just a few of them. The <soundcard.h> header file defines the following sample format identifiers: Table 3 - Sound Sample Formats Name Description AFMT_QUERY Not an audio format but an identifier used when querying the current audio format. AFMT_MU_LAW Logarithmic mu-law audio encoding. AFMT_A_LAW Logarithmic A-law audio encoding (rarely used) AFMT_IMA_ADPCM A 4:1 compressed format where a 16-bit audio sequence is represented using the average of 4 bits per sample. There are several different ADPCM formats and this one is defined by the Interactive Multimedia Association (IMA). The Creative ADPCM format used by the SoundBlaster 16 is not compatible with this one. AFMT_U8 The standard unsigned 8-bit audio encoding used in PC soundcards. AFMT_S16_LE The standard 16-bit signed little-endian (Intel) sample format used in PC soundcards.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP AFMT_S16_BE Big-endian (M68K, PowerPC, SPARC, etc.) variant of the 16-bit signed format. AFMT_S16_NE convention. AFMT_S8 Signed 8-bit audio format. AFMT_S32_LE Signed little-endian 32-bit format. Used for 24-bit audio data where the data is stored in the 24 most significant bits and the least significant 8 bits are not used (should be set to 0). AFMT_S32_BE Signed big-endian 32-bit format. Used for 24-bit audio data where the data is stored in the 24 most significant bits and the least significant 8 bits are not used (should be set to 0). AFMT_U16_LE Unsigned little-endian 16-bit format. AFMT_U16_BE Unsigned big-endian 16-bit format. AFMT_MPEG MPEG MP2/MP3 audio format (currently not supported). It is important to realize that for most devices just the 8-bit unsigned format (AFMT_U8) is supported at the hardware level (although there are highend devices which support only 16-bit formats). Other commonly supported formats are AFMT_S16_LE and AFMT_MU_LAW. With many devices AFMT_MU_LAW is emulated using a software based (lookup table) translation between mu-law and 8-bit encoding. This causes poor quality when compared with straight 8 bits. Applications should check that the sample format they require is supported by the device. Unsupported formats should be handled by converting data to another format (usually AFMT_U8). Alternatively, the program should abort if it cannot do the conversion. Trying to play data in an unsupported format is a fatal error. The result is usually just loud noise which may damage ears, headphones, speakers, amplifiers, concrete walls and other unprotected objects. The above format identifiers have been selected so that AFMT_U8 is defined as 8 and AFMT_S16_LE is 16. This makes these identifiers compatible with older ioctl calls which were used to select the number of bits. This is valid just for these two formats so format identifiers should not be used as sample sizes in programs. 16-bit signed format in machines native endian

C-DAC,Hyderabad

Real Time Data Transmission Using UDP The AFMT_S32_XX formats are designed to be used with

applications requiring more than 16 bit sample sizes. Storage allocated for one sample is 32 bits (int in most architectures). 24 bit data is stored in the three most significant bytes (the least significant byte should be set to zero). AFMT_S16_NE is a macro provided for convenience. It is defined to be AFMT_S16_LE or AFMT_S16_BE depending of endian convention of the processor where the program is being run. AFMT_S32_NE behaves in the same way. The number of bits required to store a sample is: & 4 bits for the IMA ADPCM format, & 8 bits for 8-bit formats, mu-law and A-law, & 16 bits for the 16-bit formats, and & 32 bits for the 24/32 bit formats. & undefined for the MPEG audio format. int format; format = AFMT_S16_LE; if (ioctl(audio_fd, SNDCTL_DSP_SETFMT, &format) == -1) { /* fatal error */ perror("SNDCTL_DSP_SETFMT"); exit(1); } if (format != AFMT_S16_LE) { /* The device doesn't support the requested audio format. The program should use another format (for example the one returned in "format") or alternatively it must display an error message and to abort. */ } int mask; if (ioctl(audio_fd, SNDCTL_DSP_GETFMTS, &mask) == -1) { /* Handle fatal error ... */ } if (mask & AFMT_MPEG) { /* The device supports MPEG format ... */ }

C-DAC,Hyderabad

Real Time Data Transmission Using UDP The sample format can be set using the ioctl call

SNDCTL_DSP_SETFMT. The following code fragment sets the audio format to AFMT_S16_LE (other formats are similar): Setting Sample Format The SNDCTL_DSP_SETFMT ioctl call simply returns the currently used format if AFMT_QUERY is passed as the argument. It is very important to check that the value returned in the argument after the ioctl call matches the requested format. If the device doesn't support this particular format, it rejects the call and returns another format which is supported by the hardware. A program can check which formats are supported by the device by calling ioctl SNDCTL_DSP_GETFMTS as in the listing below: Checking for Supported Formats NOTE SNDCTL_DSP_GETFMTS returns only the sample formats that are actually supported by the hardware. It is possible that the driver supports more formats using some kind of software conversion (signed to unsigned, bigendian to little-endian or 8-bits to 16-bits). These emulated formats are not reported by this ioctl but SNDCTL_DSP_SETFMT accepts them. The software conversions consume a significant amount of CPU time so they should be avoided. Use this feature only if it is not possible to modify the application to produce the supported data format directly. int channels = 2; /* 1=mono, 2=stereo */ if (ioctl(audio_fd, SNDCTL_DSP_CHANNELS, &channels) == -1) { /* Fatal error */ perror("SNDCTL_DSP_CHANNELS"); exit(1); } if (channels != 2) { /* The device doesn't support stereo mode ... */

C-DAC,Hyderabad

Real Time Data Transmission Using UDP } NOTE Applications must select the number of channels and number of bits before selecting sampling speed. There are devices which have different maximum speeds for mono and stereo modes. The program will behave incorrectly if the number of channels is changed after setting the card to high speed mode. The speed must be selected before the first read or write call to the device. AFMT_MU_LAW is a data format which is supported by all devices. OSS versions prior to 3.6 always reported this format in SNDCTL_DSP_GETFMTS. Version 3.6 and later report it only if the device supports mu-law format in hardware. This encoding is meant to be used only with applications and audio files ported from systems using mu-law encoding (such as SunOS). 2.3.6.2 Selecting the Number of Channels (Mono/Stereo) Most modern audio devices support stereo mode. The default mode is mono. An application can select the number of channels calling ioctl SNDCTL_DSP_CHANNELS with an argument specifying the number of channels (see listing 7). Some devices support up to 16 channels. Future devices may support even more. Setting Number of Channels An application should check the value returned in the variable pointed by the argument. Many older SoundBlaster 1 and 2 compatible devices don't support stereo. As well, there are high end devices which support only stereo modes. 2.3.6.3 Selecting Sampling Rate (speed) int speed = 11025; if (ioctl(audio_fd, SNDCTL_DSP_SPEED, &speed)==-1) { /* Fatal error */ perror("SNDCTL_DSP_SPEED"); exit(Error code); } if ( /* returned speed differs significantly from the requested one... */ ) { /* The device doesn't support the requested speed... */

C-DAC,Hyderabad

Real Time Data Transmission Using UDP } Sampling rate is the parameter that determines much of the quality of an audio sample. The OSS API permits selecting any frequency between 1 Hz and 2 GHz. However in practice there are limits set by the audio device being used. The minimum frequency is usually 5 kHz while the maximum frequency varies widely. Some of the oldest sound cards supported at most 22.05 kHz (playback) or 11.025 kHz (recording). The next generation supported 44.1 kHz (mono) or 22.05 kHz (stereo). With modern sound devices the limit is 96 kHz (DVD quality) but there are still few popular cards that support just 44.1 kHz (audio CD quality). The default sampling rate is 8 kHz. However an application should not depend on the default since there are devices that support only higher sampling rates. The default rate could be as high as 96 kHz with such devices. Codec devices usually generate the sampling clock by dividing the frequency of a high speed crystal oscillator. In this way it is not possible to generate all possible frequencies in the valid range. For this reason the driver always computes the valid frequency which is closest to the requested one and returns it to the calling program. The application should check the returned frequency and to compare it with the requested one. Differences of few percents should be ignored since they are usually not audible. A larger difference means that the device is not capable to reproduce the requested sampling rate at all or it may be currently configured to use some fixed rate. Also note that this call rarely returns an error (-1). Getting an OK result doesn't mean that the requested sampling rate was accepted. The value returned in the argument needs to be checked. With some professional devices the sampling rate may be locked to some external source (S/PDIF, AES/EBU, ADAT, or world clock). In this case the SNDCTL_DSP_SPEED ioctl cannot change the sampling rate, instead the locked rate will be returned. This type of exceptional condition will be explained in the README file for the particular low-level sound driver. The following code fragment can be used to select the sampling speed:

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

Setting Sampling Rate NOTE Applications must select the number of channels and number of bits before selecting speed. There are devices which have different maximum speeds for mono and stereo modes. The program will behave incorrectly if number of channels is changed after setting the card to high speed mode. Speed must be selected before the first read or write call to the device. NOTE All of these ioctl calls are likely to cause clicks or unnecessary pauses in the output. You should use them only when they are absolutely required. Other Commonly Used ioctl Calls It is possible to implement most audio processing programs without using any ioctl calls other than the three described earlier. This is possible if the application just opens the device, sets parameters, calls read or write continuously (without noticeable delays or pauses) and finally closes the device. This kind of application can be described as stream or batch application. There are three additional calls which may be required with slightly more complicated programs. All of them do not require or return an argument (just use an argument of 0). The ioctl SNDCTL_DSP_SYNC can be used when an application wants to wait until the last byte written to the device has been played (it doesn't wait in recording mode). When that occurs, the call resets (stops) the device and returns back to the calling program. Note that this call may take several seconds to execute depending on the amount of data in the buffers. Closing any sound device calls SNDCTL_DSP_SYNC implicitly. It is highly recommended that you close and reopen the device instead of calling SNDCTL_DSP_SYNC. The ioctl SNDCTL_DSP_RESET stops the device immediately and returns it to a state where it can accept new parameters. It should not be called after opening the device as it may cause unwanted side effects in this situation. The call is only required when recording ir playback needs to

C-DAC,Hyderabad

Real Time Data Transmission Using UDP be aborted. In general, opening and closing the device is recommended after using SNDCTL_DSP_RESET. The ioctl SNDCTL_DSP_POST is a lightweight version of

SNDCTL_DSP_SYNC. It just tells to the driver that there is likely to be a pause in the output. This makes it possible for the device to handle the pause more intelligently. This ioctl call doesn't block the application. There are few places where these calls should be used. You should call SNDCTL_DSP_POST when your program is going to pause continuous output of audio data for relatively long time. This kind of situation is, for example, the following: & after playing a sound effect when a new one is not started immediately (another way is to output silence until next effect starts); & before the application starts waiting for user input; & before starting lengthy operation such as loading a large file to memory. The functions SNDCTL_DSP_RESET or SNDCTL_DSP_SYNC should be called when the application wants to change sampling parameters (speed, number of channels or number of bits). However it's more reliable to close and reopen the device at the moment of parameter change. The application must call SNDCTL_DSP_SYNC or

SNDCTL_DSP_RESET before switching between recording and playback modes (or alternatively it should close and reopen the audio device (recommended)). 2.3.7 Interpreting Audio Data Encoding of audio data depends on the sample format. There are several possible formats, the most common of which are described here. Mu-law (Logarithmic Encoding) this is a format that originated from digital telephone technology. Each sample is represented as an 8-bit value which is compressed from the original 16-bit value. Due to logarithmic encoding, the value must be converted to linear format before it is used in

C-DAC,Hyderabad

Real Time Data Transmission Using UDP computations (two mu-law encoded values cannot simply be added). The actual conversion procedure is beyond the scope of this text. Avoid mu-law if possible and use the 8 or 16-bit linear formats instead. 2.3.7.1 8-bit Unsigned This is the normal PC sound card (SoundBlaster) format which is supported by practically all sound hardware. Each sample is stored in an 8-bit byte. The value of 0 represents the minimum level and 255 the maximum. The neutral level is 128 (0x80 in hexadecimal). In practice there is some noise in the silent portions of recorded files, so the byte values may vary between 127 (0x7f) and 129 (0x81). The C data type to be used is unsigned char. To convert from unsigned to signed 8-bit formats, subtract 128 from the value to be converted. Exclusive ORing value with 0x80 does the same (in C use the expression "value ^= 0x80"). 2.3.7.2 16-bit Signed CAUTION Care must be taken when working with 16-bit formats. 16-bit data is not portable and depends on the design of both the CPU and audio device. The situation is simple when using a little-endian x86 CPU with a normal soundcard. In this case both the CPU and the soundcard use the same encoding for 16-bit data. However, the same is not true when using 16-bit encoding in a big-endian environment such as SPARC, PowerPC or HP-PA. unsigned char devbuf[4096]; int applicbuf[2048]; int i, p=0; /* Place 2048 16-bit samples into applicbuf[] here */ for (i=0; i<2048; i+=2) { /* first send the low byte then the high byte */ devbuf[p++] = (unsigned char)(applicbuf[i] & 0xff); devbuf[p++] = (unsigned char)((applicbuf[i] >> 8) & 0xff);

C-DAC,Hyderabad

Real Time Data Transmission Using UDP } /* Write the data to the device ... */ The 16-bit encoding normally used by sound hardware is littleendian (AFMT_S16_LE). However there are machines with built-in audio chips which support only big-endian encoding. When using signed 16-bit data, the C data type best matching this encoding is usually signed short. However, this is true only in little-endian machines. In addition, the C standard doesn't define the sizes of particular data types so there is no guarantee that short is 16 bits long in all machines. For this reason, using an array of signed short as an audio buffer should be considered a programming error although it is commonly done in audio applications. The proper way is to use an array of unsigned char and to manually assemble/disassemble the buffer to be passed to the driver. For example: Listing 9 - Handling 16-bit Data Disassembling the data after input from the file can be performed in similar way (this is left as an exercise for the reader). The AFMT_S16_NE format can be used when a program wants to encode or decode 16-bit samples locally. It automatically selects the right format for the CPU architecture being compiled for. In this way its usually possible to simply use signed short format to store the samples. 2.3.7.3 24 and 32 bit signet formats The AFMT_S32_LE, AFMT_S32_BE, and AFMT_S32_NE formats are a 32-bit signed format which can be used to store audio data of arbitrary precision. Data smaller than 32 bits is stored left justified so that the unused bits are set to all zeroes. For example, 24-but data is store such that the 24 most significant bits are used and the 8 least significant are left as zeroes. 2.3.8 Encoding of Stereo Data

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

When using stereo data, there are two samples for each time slot. The left channel data is always stored before the right channel data. The samples for both channels are encoded as described previously. This is extended when more channels are used. For example, with 4 channels the sample values for each channel are send in turn. 2.3.8.1 Multiple channels OSS supports professional multi channel audio devices that support up to 16 (or even more) mono channels (or up to 8 stereo channel pairs). Depending on the device being used there are two different ways to handle multiple channels. In some cases the driver supports both methods at the same time. 2.3.8.2 Interleaved multi channel audio In this method there is just one device file (such as /dev/dsp) that supports multiple channels. The application can simply request multiple channels (2, 3, 4, ..., N) using the SNDCTL_DSP_CHANNELS ioctl. The multi channel data will the be encoded in similar way than with stereo so that the channel samples for every sampling period will be interleaved. 2.3.8.3 Multiple audio device method In this method there are several device files (dev/dspM to / dev/dspM+N where M is the device number of the first channel and N is the number of channels). In this way the same application or several separate applications may open the channels individually. It's also possible that the device files are organized as stereo pairs (/dev/dspM=channels0/1, /dev/dspM+1=channels2/3, etc). 2.3.8.4 Mixed multi device and interleaved method With devices that provide multiple independent device files it's also possible to use third approach that provides almost infinite flexibility. In this way one application can open one device file (say /dev/dsp0) and set it to stereo (2 channel) mode (this allocates the channel reserved for /

C-DAC,Hyderabad

Real Time Data Transmission Using UDP dev/dsp1 too). Another application may open /dev/dsp2 and set it to a 4 channel mode (so the channels of /dev/dsp3, /dev/dsp4 and /dev/dsp5 will get allocated too). Finally third and fourth applications may open / dev/dsp6 and /dev/dsp7 and then use them in mono mode. All possible channel combinations are permitted.

2.3.9 Changing mixer settings for an audio device In general it's highly recommended that audio applications don't touch the mixer settings. The idea is that users will use a dedicated mixer program to make changes in the mixer settings. An audio application changing them too is likely to cause conflicts. At least great care must be taken so that problems on the mixer side don't break the application. There are already too many good audio applications that fail because their mixer support is broken. If you really have to do mixer changes you should do the im the following way. 1) Do not open any /dev/mixer# devices. There is no way to find out which one (if any) is related with this particular audio device. Instead call the mixer ioctls (as defined in the mixer programming section) directly on the audio device file. You should not try to reopen the device again for mixer access. Just use the same file descriptor as for audio reads and writes. 2) You may only change the recording device setting and PCM volume. These are the only controls that may work in the same way with all devices. If some mixer control is missing it's not an error condition. It just means that you don't need to care about it at all. Possibly the device being used is just a high end professional device which doesn't have any unnecessary mixer devices on the signal path. 3) If you encounter any kind of error when doing mixer access just ignore the situation or (preferably) stop trying to do any further mixer operations. The worst mistake you can do is aborting the application due to a mixer problem. The audio features of your application will still work even the mixer access fails (these two things are completely unrelated).

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

3.The Data Encryption Standard (DES)

3.1 Introduction The most widely used encryption scheme is defined in the Data Encryption Standard (DES) adapted in 1977 by National Institute of Standards And Technology (NIST). 3.2 Encryption and decryption scheme The overall scheme of DES encryption is illustrated in figure A. As with any encryption scheme there are two inputs to the encryption function: the plain text to be encrypted and the key. In this case, the plain text to be 64 bits in length and key is 56 bits. The processing of plain text proceeds in three phases. First the 64 bit plain passes through an initial permutation (IP) that rearranges the bits to produce the permuted input. This IP is followed by a phase consisting of 16 iterations of the same function. The output of the last (16) iteration consists of 64 bits that are a function of the plaintext input and the key. The left and right halves of the output are swapped to produce the preoutput. Finally the pre output which passes through a permutation (1/IP). i.e. the inverse of the initial function, in order to produce the 64 bit cipher text. The right hand portion of the figure shows the way in which the 56 bit key is used. Initially, the key is passed through a permutation function. then, for each of the 16 iterations, a sub key (Ki) is produced by the combination of a left circular shift and a permutation. The permutation function is the same for each iteration, but a different sub key is produced, because of repeated shift of key bits. Figure B examines more closely the algorithm for single iteration. The 64 bit permuted input passes through 16 iterations, producing an intermediate 64 bit value at the conclusion of iteration. the left and right half of each 64 bit intermediate value are treated as separate 32 bit

C-DAC,Hyderabad

Real Time Data Transmission Using UDP quantities, labeled L(left) and R(right). The overall processing at each iteration can be summarized in the following formulae. Li=Ri-1 Ri =Li-1 XOR f (Ri-1, Ki) Thus, the left hand output of the iteration Li is simply equal to the right hand input to that iteration Ri-1. The right hand output Ri is the exclusive or of Li-1 and the complex function f of Ri-1 and Ki. This complex function involves both permutation and substitution operations. The substitution operation, represented as tables called S-boxes simply maps each combination of 48 input bits into a particular 32 bit pattern. Returning to figure A. we saw that the 56 bit key used as input to the algorithm is first subjected to a permutation. The resulting 56 bit key is then treated as two 28 bit quantities, labeled Co and Do. At each iteration, C and D are separately subjected to a circular left chit, or rotation, of one or two bits. These shifted values serve as input to the next iteration. They also serve as input to another permutation function, which produces a 48 bit output that serves as input to the function f (Ri-1, Ki). The process of decryption with DES algorithm is same as the encryption process. The rule as follows: use this cipher text as input to the DES algorithm, but use the keys Ki in the reverse order. i.e., use K16 on the first iteration, K15 on the second iteration and so on, until K1 is used on the last iteration. 3.3 THE STRENGTH OF DES: Since its adoption as a federal standard, they have been lingering concerns about the level of security provided by DES. These concerns, by and large, fall into two areas: the nature of the algorithm and the key size.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP For many years the more important concern was the possibility of exploiting the characteristic of DES algorithm to perform the crypt analysis. The focus of concern has been on eight substitution tables. Because the design criteria for these boxes, and really for the entire algorithm, have never been made public, there is suspicion that the boxes are constructed in such a way that crypt analysis is possible for an opponent who knows the weaknesses in S-boxes. This assertion is tantalizing, and over the years the number of regularities and unexpected behaviors of the S-boxes have been discovered. Despite this problem no one has so far succeeded in discovering the supposed fatal weaknesses in the S-boxes. Indeed, as advances in the crypt analytic techniques have occurred, the underlying strength of DES algorithm has been more apparent. It is probably safe to say that DES is one of the strongest algorithms ever devised. The most serious concern, today is the key size, with a key length of 56 bits, there are 256 possible keys, which is approximately 7.6x1016 keys. Thus on the face of it, a brute-force attack appears in practical. Assuming that on average half the key space has to be searched, as ingle machine performing one DES encryption per microsecond would take more than a thousand years to break the cipher

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

4.User Datagram Protocol (UDP)

4.1 Introduction UDP (user datagram protocol) is a connectionless, unreliable transport protocol. It does not add anything to the services of IP (internet protocol) except for providing process- to - process communication instead of host-to-host communication. Also, it performs very limited error checking. But UDP is having some advantages like; it is a simple protocol with minimum overhead. it can use in a situation like a process want to send a small message and does not care much about reliability and it takes less interaction between sender and receiver than it does in TCP. 4.2 Header Format UDP packets have a fixed-size header of eight bytes. The fields of the packet header are as follows, Source port number:This is the port number used by the process running on the source host. If the source host is the client then the port number in most cases is an ephemeral port number requested by the process and chosen by the UDP software running on the source host. If the source host is the server then the port number in most cases is a wellknown port number. Destination port number:This is the port number used by the process running on the destination host. If the destination is server it will be a well-known port number. If it is client it will be ephemeral port. Length:This field that determines the total length of the user datagram, header plus data. Checksum:this field is used to detect errors over the entire user datagram (header plus data).The Calculation of Checksum and Its Inclusion in a User Datagram Is Optional.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP 4.3 Applications of UDP The following lists some of the UDP protocol, UDP is suitable for a process that requires simple request-response communication and with little concern for flow and error control. It is not usually used for a process that needs to send bulk data, such as FTP. UDP is suitable for a process with internal flow and error- control mechanisms. (eg.TFTP). UDP in the TCP. UDP is used for management processes such as SNMP. UDP is used for some route updating protocols such as routing information protocol (RIP). is a suitable transport protocol for multicasting and

broadcasting. because these capabilities are embedded in the UDP but not

4.4 Programming of UDP (socket programming): Sockets:The communication structure that we need in socket

programming is a socket. A socket acts as an end point. Two processes need a socket at each end to communicate with each other. Socket is defined as port number plus IP address. Socket structure:it consists of the following fields. Family:this field defines the protocol group (IPV4, IPV6, UNIX domain protocols and so on). Type: this field defines the type of the socket (stream or datagram or raw socket).

C-DAC,Hyderabad

Real Time Data Transmission Using UDP Protocol: this field is usually set to zero for TCP and UDP. Local socket address: This field defines the local socket address. a structure of type sockaddr_in. Remote socket address: this field defines the remote socket address. a structure of type sockaddr_in. Network byte order:Networking protocols can choose their own byte order. The TCP/IP protocol suite has chosen the big-endian byte order. Byte order transformation: TCP/IP software provides a set of functions that transforms integers from a host byte order to network byte order. the APIs available are, htons: This converts 16 bit integer from host byte order to network byte order. ntohs: This converts 16 bit integer from network byte order to host byte order. htonl: This converts 32 bit integer from host byte order to network byte order. ntohl: This converts 32 bit integer from network byte order to host byte order. Address transformation:Network software provides functions to

transform an IP address from ASCII dotted decimal format to 32-bit binary format and vice versa. The following APIs are available, inet_aton:This function transforms an ASCII string that contains up to four segments separated by dots to a 32-bit binary address in network byte order. int inet_aton(const char *strptr,struct in_addr *addrptr);

C-DAC,Hyderabad

Real Time Data Transmission Using UDP inet_ntoa: This function transforms a 32-bit binary address in network byte order to an ASCII string with four segments separated by dots. int inet_ntoa(struct in_addr *inaddr); Socket system calls: Several functions have been defined that can be called by an application program to communicate with another application program. Some of them are as follows, Socket: This function is used by a process to create a socket. int socket (int family,int type,int protocol); Bind:This function binds a socket to a local address by adding the local socket address to an already created socket. int bind (int sockfd,const struct sockaddr_in *localaddr, int localaddrlen); Connect: This function is used by a process (usually a client) to establish an active connection to a remote process (normally a server). int connect (int sockfd,const struct sockaddr_in *serveraddr, int serveraddrlen); Sendto: This function is used by a process to send a message to another process usually running on a remote machine. int sendto (int sockfd,const void *buf,int buflen,int flags,const struct sockaddr_in *toaddr, int toaddrlen); Recvfrom: The receive function extracts the next message that arrives at a socket. It also extracts the sender socket address. In this way, the process that uses this function can recalled the socket address and uses it to send a reply back to the sender. int recvfrom (int sockfd,const void *buf,int buflen,int

flags,const struct sockaddr_in *fromaddr, int fromaddrlen);

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

Conclusion
The project dealt with real time voice(data) transsmission using UDP. The data is encoded using 8-bit unsigned through codec.This encoding technique is simple and easy to implement. The data is encrypted using Data Encryption Standard (DES) algorithm.This algorithm is one of the highly proven algorithms and thus chosen in this project for providing security.This algorithm simple to implement and satisfies the soft real time requirements. User Datagram Protocol is chosen for transmission of data as it is fast and less overhead thus satisfying real time requirements. This project finally concluded that the above combination is found suitable for voice transsmission with security satisfying soft real time application requirements.

C-DAC,Hyderabad

Real Time Data Transmission Using UDP

References
1. TCP/IP PROTOCOL SUIT -Forouzen 2. Data and COMPUTER communication -William Stallings 3. RFC for UDP 4. http://www.opensound.com

C-DAC,Hyderabad