Testing and Optimizing Your Audio Device with pjsystest

Table of Contents Objectives Using pjsystest Configuring Test Parameters Invoking On Windows Invoking On Linux/MacOS X Invoking On Windows Mobile Invoking on Embedded Targets Running the application Getting the result Limitations Tasks Testing different audiodev API backends Testing different audio buffer size Testing different audio device clock rate

The pjsystest is a new application introduced in PJSIP version 1.4 by ticket #920. The objective of this application is to find out the characteristics of the target platform/device. Initially it only supports detection of various audio parameters (which will be explained shortly below), but in the future it can be extended to support other things such as network and NAT characteristic of the deployment.

By using pjsystest we can fine tune the application settings to get the most optimal setup for the target device.

Objectives

The objectives are:

• to eliminate audio impairments such as audio stuttering
• to minimize audio latency

Using pjsystest

Configuring Test Parameters

Test parameters (such as device IDs, clock rate, number of channels, and default file paths) are hardcoded in pjsystest/systest.h. You may need to modify these parameters, especially if you want to test with specific settings.

Invoking On Windows

With Visual Studio 6 and 2005,:

• compile PJSIP distribution as usual
  • with VS6, you need to select pjsystest as the active project and build the project
• run pjsystest application from Visual Studio

These additional steps are required for PJSIP version prior to 1.5:

• copy these two WAV files from tests\pjsua\wavs directory to pjsip-apps\build directory:
  • input.8.wav
  • tock8.wav
• If you invoke pjsystest from Windows Explorer, copy the two WAV files to pjsip-apps\bin directory too.

Invoking On Linux/MacOS X

Just build the distribution and run pjsystest from pjsip-apps/bin directory.

These additional steps are required for PJSIP version prior to 1.5:

Same as above, except you need to copy the two WAV files to whatever directory you plan to invoke pjsystest from (normally pjsip-apps/bin directory).

Invoking On Windows Mobile

With Visual Studio, it can't be simpler:

• build the distribution and pjsystest
• run pjsystest from the IDE
• the EXE and the required WAV files will be deployed to the device automatically

Invoking on Embedded Targets

• build the distribution
• copy pjsystest executable from pjsip-apps/bin and deploy to target
• also deploy these two files from tests\pjsua\wavs directory to the same directory in the target device as the pjsystest executable:
  • input.8.wav
  • tock8.wav
• run pjsystest on the target device

Running the application

Once the application is running, just choose "Test Wizard" to run all the tests, and follow the wizard instruction.

The console application may be a bit awkward to use with all the dialog box emulation, but it works (and that's the best we can do for now).

Getting the result

No need to have pen and paper to note the result, they are recorded to PJSYSTEST_RESULT.TXT file once you exit the program. On Windows Mobile, the file location is in the root device, while on other targets it is in the directory where the application is run from.

Additional info and instructions are given as you are running the application.

Limitations

• by design, pjsystest would not be able to test audio latency if audio switchboard is used instead of the default conference bridge

Tasks

Several things that you could experiment with using pjsystest:

Testing different audiodev API backends

Some targets such as Windows Mobile as well as desktop platforms offer more than one audiodev API backends (for example on WM there are PA/WMME and native WMME). You don't need to recompile the whole library to experiment with different audiodev API backends, just change REC_DEV_ID and PLAY_DEV_ID in systest.h.

Testing different audio buffer size

Change OVERRIDE_AUDDEV_REC_LAT and OVERRIDE_AUDDEV_PLAY_LAT in systest.h to experiment with different audio buffer size (values are in milliseconds). The objective is to get the minimum latency without getting audio impairments.

Testing different audio device clock rate

Choosing higher clock rate in audio device can minimize latency. Change DEV_CLOCK_RATE in systest.h to experiment with different clock rates.