Specifics of Testing of Sound Redirection in Terminal Sessions

Nowadays, software virtualization systems have become widespread. The end user can use virtual applications and desktops. When creating such virtualization systems, developers take into account the customer preferences (the end-user preferences) and usability. That is why, testers face a lot of diverse functionality when testing them. One such functionality is the redirection of sound to the terminal session.

In this article, we will examine the specifics of testing of sound redirection in terminal sessions. We will also consider main notions of digital sound, sound settings, and instruments, which are required for testing.

Main Notions of Digital Sound

Sound digitization and its storage on digital data medium

Let’s remember main notions and formats of digital sound to test the sound redirection. As the computer handles data in a digital form, we should understand that the sound we hear in the computer is also stored in digital form. The real sound looks as follows (Figure 2.1):

Figure 1

It is clear from the graph (Figure 1) that the sound wave is a complicated function that represents the dependence of the amplitude on time. But it is impossible to store it in the form of formula on the computer, so the function is described by a set of its discrete values in definite points (Figure 2):

Figure 2

The set of these numbers is the digitized sound that can be easily stored in the computer memory.

Types of sound formats

The file format defines the structure and peculiarities of representation of sound data when storing on the PC storage device. To avoid the redundancy of audio data, audio codecs are used. The audio data compression is performed with the help of these codecs.

There are three groups of audio file formats:

• Audio formats without compression, such as WAV, AIFF;
• Audio formats with compression without the loss (APE, FLAC);
• Audio formats with compression and loss (mp3, ogg).

Let’s examine the attribute of digital audio, a bit rate.

Bit rate is an important characteristic of digital audio that is responsible for the sound quality. The understanding of this characteristic is very important as we will examine the testing of quality of the sound redirected to the terminal session.

Bit rate is a number of bits that are necessary for storing (transferring) of one second of data stream (usually, audio and video files). It is usually measured in ‘kbps’ — kilobit per second.

This term is often used as a characteristic for estimation of work efficiency of algorithms of information compression with loss.

Bit rate characterizes both the information packing factor and its quality. For example, of two MP3 files compressed with different bit rates, the file with greater bit rate has the most qualitative (close to the original) sound. At the same time, the file of another format with equal bit rate can give both better and worse sound quality.

Main Types of Testing

The main types of testing of sound redirection are the configuration and functional testing. Next, we will examine them in details.

Configuration Testing

As we test the sound redirection, we, naturally, have the client-server application. We will test the sound redirection from the client to server (desktop).

Both the client and the server can have different operating systems and the hardware. That is why we need to perform the configuration testing. This type of testing makes it possible to ensure that the product behaves correctly on different operating systems with different hardware and software.

There are often computer requirements in the project documentation, such as RAM – 512 Mb, video – 128 Mb, OS – Windows XP sp3 x32/x64, Windows 7 Ent x32/x64, Windows Server 2003 sp2 x32, etc.

Testing of the main project functionality on each configuration takes long (according to statistics, 40 man-days for an average project). That is why we should remember which applications the end users will most probably use (the configuration priority) when preparing the configuration matrix (also called “cover matrix”).

Here is an example of configuration matrix (Table 1). All possible configurations defined in the product requirements with defined priorities are filled in it:

Table 1. Configuration matrix

Functional Testing

In this part of the article, we will examine how and with the help of which program means we can organize the functional testing of sound redirection in terminal sessions.

Both the terminal server (e.g., Windows Sever 2003 sp2 x32) and a usual VDI (e.g., Windows XP sp3 x32) can be the server (desktop). That is why there are differences in the server component settings. For example, there are no Remote Desktop Session Host Configuration settings in VDI server –  so, if you test with VDI, settings in Remote Desktop Session Host Configuration should be omitted. But all other settings, especially those connected with the sound redirection, are identical.

One more important rule: when testing, you should start only one terminal session.

Starting the sound redirection to the terminal session

To do this, you should be added to the local administrators group or you should be delegated the corresponding authority (i.e., Permissions ->Full Control).

To start the sound redirection using Remote Desktop Session Host Configuration, do as follows:

1. On the terminal server, select Start ->Administrative Tools -> Remote Desktop Services ->Remote Desktop Session Configuration.
2. Under the Connections header, right click RDP-TCP and select Properties.
3. Select the Client Settings tab.
4. Uncheck the Audio and video playback and Audio recording options.

Changing group policy parameters

If the redirection of Plug and Play devices was disabled using Group Policy on the terminal server, we need to change group policy parameters. We can manage the redirection of Plug and Play devices with the help of the following group policy parameters:

1. Select Start -> gpedit.msc.
2. Select Local Computer Policy->Computer Configuration->Administrative Templates->Windows Components->Remote Desktop Services->Device and Resource Redirection.
3. In the list to the right, right click Allow audio redirection and select Edit.
4. Select Enabled and click Apply. Then, click OK.

(For more information about setting the group policy parameters, see http://go.microsoft.com/fwlink/?LinkId=143317)

Let’s check if audio is redirected to the terminal session. Do as follows:

1. Establish connection with the terminal server.
2. Start the Windows Audio service (Start -> Administrative Tools -> Services -> Windows Audio Service).
3. Select Start -> Control Panel -> Sound.
4. On the Playback tab, make sure that the remote audio is displayed in the list of playback devices.
5. On the Recording tab, make sure that the remote audio is displayed in the list of recording devices.

If the playback and recording devices were redirected to the session, then, we can start testing of the sound itself.

The specifics of testing of sound redirection are as follows:

• Testing of the sound quality;
• Testing of the network buffering;
• Testing of the microphone.

Testing of Audio Quality

The audio quality is defined by the bit rate.

In the tested application, audio settings transferred to the terminal session can look as follows, for example:

where 64 kbps (64 kilobits per second), 128 kbps…256 kbps is the value of the bit rate.

We should understand that the higher the bit rate is the bigger and more qualitative is the file. It means that we can define what audio quality is transferred to the session by measuring the number of received bytes per second in the session.

Also, the audio settings can look as follows:

where CD Quality – the quality of CD (it is the highest, 256 kbps), Radio Quality – the quality of radio  (it is bad, 64 kbps), and Telephone Quality – the quality of the telephone (it is suitable only for speech).

We can use the following programs to test the quality of the audio transferred to the terminal session: BWMeter, perfmon (standard Windows program), NetLimiter, and other programs, with the help of which we can monitor traffic.

There is no difference what tool to use when testing; the only difference is in the tool settings. You can use the one that is convenient for you.

Testing of audio quality transferred to the terminal session:

On the client:

1. Select the tested quality of the audio transfer (e.g., 64 kbps);
2. Start the Remote Desktop Session (terminal session).

In the session:

1. Start any audio file with quality record (e.g., *.mp3 file);
2. Minimize the player window but do not close it! The audio file must play.
3. Check if the corresponding audio quality is applied in the session:

With the help of BWMeter

1. Start the BWMeter in the session (available for download at http://www.izone.ru/internet/dial/bwmeter.htm )

Two graphs appear. We need only the Local Network graph as we will look at the number of transferred bytes to the client in the local network.
In options, we can change it so that the number of transferred bytes from the session to the client is calculated in kilobits (kbps). To do this, click Local Network (or LAN) graph, open Graphs, and select the option

1. Look at the graph and wait for 30-60 seconds to play the file (it is enough to define an average amount of Upload traffic).
2. Look at the average value of UL (Upload) traffic. In our case, BWMeter shows the average value of UL traffic = 68 kb/s but this parameter can vary. This value depends also on the depth of the color transferred to the session, loaded and/or residing in the process list applications. That is why, if the UL value is 64 < UL < 96, audio with 64 kbps quality is transferred to the session. Thereby, we can say that the sound quality we chose (64 kbps) is redirected to the session.

With the help of Perfmon

1. Start perfmon in the session (Start-> Run-> perfmon).
2. Add the required counter of sent bytes from the session to the client.

1. Look at the graph and wait 30-60 seconds to play the file.
2. Look at the “Average = 8416 bytes/sec” value.

Convert it to kilobits per second:

• 8416*8 = 67328 bit/sec;
• 67328/1024 = 65 kilobit/sec (65 kbps).

Similarly, we can say that the quality of the sound we chose (64 kbps) is redirected to the session.

Testing of Network Buffering

There can be network buffering settings in the tested application.

This feature provides with an excellent playback of extended audio fragments (e.g., MP3). The bigger the buffer is, the more qualitative the audio playback is. The buffer size is defined in seconds. For example, we’ve set it to 3 seconds of content.

To check if the buffer is applied, you should do as follows:

On the client:

1. In the Network buffering settings, select the Buffer option and set its value as 3.
2. Start the session (desktop).

In the session:

1. Start the playback of any audio file in the session.
2. Click Stop in the player.
3. After clicking Stop, the audio file must play for 3 seconds more (you can note it down with the help of the stopwatch).

Thereby, if the audio file plays for 3 seconds more (depending on which buffer size you select), the feature is working.

Testing of Microphone Settings

When testing audio, we face testing of microphone settings. The microphone is connected to a special input of the sound card and is detected by the operating system as a standard audio input device that does not require additional software for its support.

To configure your microphone, you should do as follows:

1. Connect the microphone to the computer (client).
2. Check if the microphone is displayed in audio devices (Start->Control Panel->Sound, Speech and Audio Devices->Sound and Audio Devices).
3. Check its workability with the help of Sound Record (sndrec.exe in WinXPx32).

If the microphone functions well on the client, we can start testing of redirection of microphone settings to the session. Supposing, microphone settings in the tested application look as follows:

where

• Use compression – this option is responsible for compression of the audio signal transferred to the session;
• Use enhancement – this option is responsible for improvement of the compression quality of the audio signal transferred to the session. If it is selected, the following parameters are available:
• Quality – parameter that is responsible for the quality of the audio signal transferred to the session. When moving the slider to Low, we will listen to rather intelligible speech (but with noise) in the session; when moving the slider to High, we will listen to an excellent speech;
• Complexity (CPU usage) – this parameter is responsible for the complexity of the algorithm of audio signal compression. The more complex the compression algorithm is, the more resources are required (especially CPU).

All these parameters for the microphone setting are created to considerably improve the quality of the transferred signal to the terminal session. And the most important is that the user who works with the remote server (desktop) can set all parameters himself and listen audio on the remote desktop taking into account his computer parameters.

To test the microphone settings, it is enough to do as follows:

On the client:

1. For example, first, set the microphone parameters to the lowest values (Quality =  Low).
2. Start any qualitative audio file.

In the session:

1. Start the Sound recorder (sndrec.exe, any other program for audio recording from the microphone).
2. Start recording (60 seconds are enough).
3. Save the file (low.wave).
4. Log off the session.

On the client:

1. Set the highest values of parameters (Quality = High).
2. Restart any qualitative audio file.

In the session:

1. Start the Sound recorder (sndrec.exe, any other program for audio recording from the microphone).
2. Start recording (60 seconds are enough).
3. Save the file (high.wave).

Then, you can aurally verify the sound quality of audio files with Quality =  Low (low.wave) and Quality = High( high.wave) parameters. Be sure, the sound quality of two files will differ a lot.

The Complexity parameter is checked in the same way.

Also, it would be a good thing to test the microphone redirected to the terminal session for interaction, for example, with different communicators, such as Skype, ICQ, MS Office Communicator, or Adobe Connect.

Conclusion

Now we see that many interesting things concern the audio testing, such as testing of audio quality, testing of network buffering, testing of microphone settings, and testing of interaction with different program communicators (e.g., Skype, ICQ, MS Office Communicator, or Adobe Connect). Also we should not forget about configuration testing.

And the most important is that we must know, at the minimum, what the digital audio is, understand its basic characteristics, and know what influences the audio quality (bit rate and codec) to work with the audio data. Also it is necessary to have experience in administration and work with programs that measure the traffic in the network (BWMeter, perfmon, NetLimiter, etc.) to perform testing.

Read more in our QA Blog –  Software Testing Estimation Techniques.