Modifying the Waveform Audio Driver Test (Windows CE 5.0)
The Waveform Audio Driver Test executes the s tux –o –d wavetest command line on default execution. This command plays and captures tones of 1 second in length on the first waveform device and performs basic functional testing. To perform in-depth testing of your driver, you must set up your device with a microphone and speaker and turn on interaction so that you can confirm that audio plays and records.
To set up the test correctly, connect a speaker and a microphone to the audio card simultaneously and place the microphone between 1 and 6 inches from the speaker. While you run the test for the first time, you may adjust this distance between the speaker and the microphone to reduce feedback and find the distance where the sound played by the test is similar to the sound that is recorded. A difference in volume between the sound played and the sound recorded is not a problem and is to be expected during the test.
You can modify the test by editing the command line. For information about how to edit the command line for a test, see Editing the Command Line for a Test. The following table shows the modifications you can make to the test.
To modify the Waveform Audio Driver Test
| To do this | Add this command-line parameter |
|---|---|
| Force the test to stop and prompt you for confirmation.
You can run the test with this command-line parameter to manually confirm that audio plays and records correctly. |
|
| Run the tests on a headless device. Prompts will be textual in the debug output. Interactive input will be entered through a keyboard attached to the headless device.
This parameter is designed to be used with the -i parameter above, thus allowing you to run the CETK tests in interactive mode on a headless device. (The system must have at least SYSGEN_MININPUT level of input support present.) |
|
| Set 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. |
|
| Enable 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.
You need to use this parameter if your driver or hardware cannot play and capture sound simultaneously. |
|
| Specify which device to test.
If your device is not the default device, use this parameter to specify that the device must be tested. |
|
To specify one or more optional command-line entries in the test library, you must use the –c tux option. The -c option forces Tux to pass the optional command-line entry into the test library. For example, the s tux -o -d wavetest -c "-i -d 5 -e" command line runs the test interactively with tones of 5-second duration and tests the driver as a half-duplex driver.
The following table shows the test cases for the Waveform Audio Driver Test.
| Test case | Description |
|---|---|
| 100: Build Verification Test | Ensures that the functionality necessary for the test is present. Refer to the test result to determine the likely cause of failure. Warnings that affect the behavior of the test will also appear in this test case if appropriate. This test case can cause other test cases to be skipped if required functionality is not present. |
| 1000: Easy Playback | Exercises the PlaySound and sndPlaySound APIs on wave files in the Windows directory. |
| 2000: Playback Capabilities | Displays the capabilities reported by the driver, and lists the extended functions supported by the driver. |
| 2001: Playback | Plays a tone for all of the supported formats. |
| 2002: Playback Notifications | Plays audio using null, event, thread, function, and window callbacks that should be supported by the driver. |
| 2003: Playback Using Extended Functions | Plays changing extended functions such as pitch, rate and volume. |
| 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. |
| 4000: Test Volume Control | Uses the audio mixer to obtain the current volume level and to set the volume level. |
| 5000: Test Power Down/Up with PlaySound Synchronus | Tests audio using PlaySound Synchronus accross a power Down/Up cycle. |
| 5001: Test Power Down/Up with PlaySound Asynchronus | Tests audio using PlaySound Asynchronus accross a power Down/Up cycle. |
| 5002: Test Power Down/Up with sndPlaySound Synchronus | Tests audio using sndPlaySound Synchronus accross a power Down/Up cycle. |
| 5003: Test Power Down/Up with sndPlaySound Asynchronus | Tests audio using sndPlaySound Asynchronus accross a power Down/Up cycle. |
| 5004: Test Power Down/Up with waveOutWrite | Tests audio using waveOutWrite accross a power Down/Up cycle |
Remarks
This test library can have one or more optional command-line entries to change the behavior of the test. To specify one or more 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.
Full duplex drivers are typically tested with the s tux -o -d wavetest -c "-i -d 5" command line, which uses 5-second tones and prompts for confirmation.
Half duplex drivers are typically tested with the s tux -o -d wavetest -c "-i -d 5 -e" command line, which also uses 5-second tones and prompts for confirmation. You must provide sound when the device records because the hardware or driver does not support playback and capture simultaneously.
Full duplex drivers on a headless device/image are typically tested with the s tux -o -d wavetest -c "-i -h" command line.
Headless Tests: Headless Images 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 the headless device.)
Note Make sure you are reading the debug spew since that is where you will be prompted by text for an interactive user response.
Volume Tests using the Mixer: These tests will skip if there is no mixer device present on the system.
Power Management Tests: These tests will skip if the power manager is not present on the system.
See Also
Send Feedback on this topic to the authors