Full-duplex Audio Playback and Record Verification (Compact 7)
3/12/2014
The Full-duplex Audio Playback and Record Verification test exercises waveform audio functionality for audio drivers. The test verifies that the driver can playback and capture supported formats in full-duplex through the Waveform Audio application programming interface.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The following tables show the hardware requirements for this test.
| Requirement | Description |
|---|---|
Audio card |
An audio card that supports full-duplex audio and is compatible with Windows Embedded Compact. |
Keyboard |
Needed for a device without a graphical user interface (GUI). |
The following tables show the software requirements for this test.
| Requirement | Description |
|---|---|
Tux.exe |
Test harness, required for executing the test. |
Kato.dll |
Logging engine, required for logging test data. |
Wavetest.dll |
Test library. |
At least 0.3 megabytes (MB) of free storage memory |
If there is not sufficient space in the root directory of the target device, the test cannot run properly. |
At least 1.0 MB of free program memory on the target device |
If there is not sufficient program memory on the target device, the test cannot run properly. |
SYSGEN_MININPUT and any dependencies |
Images that are designed to work on a device without a graphical UI require SYSGEN_MININPUT and any dependencies therein to be present on the system. (This is the minimum requirement for Keyboard support which is needed to get the interactive user input from a device without a graphical UI.) |
In order for the Waveform Audio Driver Test to function correctly you must have included the waveform audio component, SYSGEN_AUDIO, as well as an audio driver in your OS build using BSP_WAVEDEV_<driver_name> or BSP_AUDIO_<driver_name>. Some board support packages (BSPs) include an audio driver by default.
Subtests
The table below lists the subtests included in this test.
| SubTest ID | Description |
|---|---|
3000 |
Capture Capabilities. Displays the capabilities reported by the driver. |
3001 |
Capture. Captures a tone for all of the supported formats. |
3002 |
Capture Notifications. Captures audio using thread, window and function callbacks that should be supported by the driver. |
3003 |
Capture Buffer Freed During Capture. Allocates buffer in the virtual address space of the calling process for capture and frees and releases this buffer while in capture. |
3006 |
Capture Initial Latency. Verifies that average initial latency of a single buffer capture is within acceptable range. |
3007 |
Capture Initial Latencies Series. Verifies that average initial latency of a single buffer capture is within acceptable range for varying record times. If wave format is not specified at command prompt then this test case will repeat for every wave format specified in the latency test table. |
3008 |
Capture Multiple Streams. Verifies the ability to capture multiple audio streams simultaneously. |
6001 |
Capture Mixing. Verifies capture mixing by first initiating capture and then invoking PlaybackMixing to launch a series of sound threads. It also supports an interactive command line option, which allows the user to monitor the test and fail it, if the sound quality is unacceptable. |
7000 |
International Audio File Names. Exercises PlaySound and sndPlaySound methods for properly handling Unicode strings containing international characters. |
8000 |
Verify Handle Validation. Exercise audio methods for properly handling invalid handles passed to them as parameters. |
8001 |
Verify Device ID Validation. Exercise audio methods for properly handling invalid device ids passed to them as parameters. |
8002 |
Verify GUID Validation. Exercises waveOutGetProperty and waveOutSetProperty for properly handling invalid GUIDs passed to them as parameters. |
Setting Up the Test
The sound card or audio driver must be installed and active.
Running the Test
This test library can have one or more optional command line entries to change the behavior of the test. To specify the optional command-line entries to the test library, you must use the -c command line option. This option forces Tux to pass the specified string into the test library.
Note:Make sure you are reading the debug output, since that is where you will be prompted by text for an interactive user response.
The following table shows the optional command line parameters.
| Command line parameter | Description |
|---|---|
"-i" |
Forces the test to stop and prompt you for confirmation. You can run the test with this parameter to manually confirm that audio plays and records correctly. |
"-h" |
Run the tests on a device without a graphical UI. Prompts will be textual in the debug output. Interactive input will be entered through a keyboard attached to the device without a graphical UI. This parameter is designed to be used with the -i parameter, thus allowing you to run the tests in interactive mode on a device without a graphical UI. (The system must have at least SYSGEN_MININPUT level of input support present.) |
"-d duration" |
Sets the duration of the tone being played or captured for all test cases. Duration is given in units of seconds. The default value is 1 second. |
"-e" |
Enables half-duplex testing and disables sound output when capturing. You must supply your own sound into the microphone when the test attempts to record sound. |
"-wo device_identifier" |
Specifies which Wave Output device to test. If your device is not the first output device, use this parameter to specify which device must be tested. The default value is zero. |
"-wi device_identifier" |
Specifies which Wave Input device to test. If your device is not the first input device, use this parameter to specify which device must be tested. The default value is zero. |
"-c path\filename" |
Specifies the path and filename of the CSV file in which to output latency test results. The default is to not save the results. If you specify -c but do not specify path\filename then the result is stored in \release\audio_latency_test_results.csv. The default file extension is .CSV. |
"-f d_f_c_b" |
Specifies the latency test duration and wave characteristics. *d = playback/capture duration in milliseconds; default value is 1000. *f = the sample frequency; default value is 11025. *c = number of channels; default value is 1. *b = number of bits per sample, either 8 or 16; default value is 8. |
"-v path\filename" |
Saves the audio file created by the playback interoperability test. Default is to not save the file. If you specify -v but do not specify path\filename then the file will be saved as \release\WaveInterOp.wav. Default file extension is .WAV. |
"-ao duration" |
Sets the expected playtime allowance for playback test cases. Duration is given in units of milliseconds. If the test case takes more time than ‘expected playtime + allowance’ or less time than ‘expected playtime - allowance’ for playback, then the test case will fail. The default value is 200 milliseconds. |
"-ai duration" |
Sets the expected capture time allowance for capture test cases. Duration is given in units of milliseconds. If the test case takes more time than ‘expected capture time + allowance’ or less time than ‘expected capture time - allowance’ for capture, then the test case will fail. The default value is 200 milliseconds. |
"-p" |
Enables Power Management tests. By default, power management tests are skipped as not all systems support power management. |
"-s duration" |
Sets the sleep interval for CALLBACK_NULL for all of the test cases. Duration is given in units of milliseconds. The default value is 50 milliseconds. |
"-t threads" |
Sets the number of threads for audio stability tests. This parameter is used by playback and capture mixing test cases to stress the system by launching the number of threads. The default value is 9 threads. The maximum value you can specify is 40 threads. |
"-?" |
Shows a help message containing all the parameters and their descriptions. |
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all sub-tests
Troubleshooting the Test
The following table shows troubleshooting tips.
| Item | Solution |
|---|---|
The Power Management Tests are skipping. |
These tests will skip if the power manager is not present on the system. |
The Capture Multiple Stream Tests are skipping. |
These tests will skip if the device driver does not support multiple capture streams. |
If the build verification test (test case 100) determines that required functionality is not present, it may skip other test cases.
For additional platform specific issues, consult the CTK articles on the TechNet wiki.