Quality/TestSuite/Audio Driver Test Specification

Latest revision as of 12:17, 17 December 2010

Introduction

The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system.

Test Coverage

Software Coverage

blts-alsa-core package uses the interface specified in asound.h to test kernel's sound core and drivers. ALSA's user space library (alsa-lib) is not used. In addition the test asset uses V4L2 API to control FM tuner.

Current BLTS ALSA core test coverage matrix:

• [ALSA-core-coverage.ods]

Hardware Coverage

Hardware coverage includes audio devices (soundcard, FM radio, etc)

Limitations

The tests do not currently support verifying the sound passing through the audio path. Instead, the tester needs to listen to the produced audio to determine final results.

Support for various playback and capture parameters is missing, such as unsigned sample formats, and memory mapped non-interleaved access method. See section "Configuration file format" for supported parameters.

Future Improvements

Extend coverage, add support for various missing PCM settings.

Recorded PCM data should be stored to a file for external verification, or the data should be verified by the test asset automatically.

Building packages

The build environment must have the following packages installed:

• libbltscommon-devel
• kernel-headers
• dbus-glib-devel
• glib2-devel

The source package includes the pack.sh script, which is used for building RPM and Debian packages and source tar packages. To build an RPM package with the script, execute this command in the top level source directory of asset:

./pack.sh -r

To get help about the packaging script, execute

./pack.sh -h

The asset can also be built manually by executing:

./autogen.sh
./configure
make

Running the tests

The test environment must have following packages installed:

• libbltscommon1

The test package and associated configuration pacakge can be installed in the device with a command:

rpm -ivh blts-alsa-core-tests-{version}.rpm blts-alsa-core-tests-config-{platform}-{version}.rpm 

Configuration package/file is platform dependant, see section "Configuration"

Run as root: $ blts-alsa-core-tests

This will execute the test cases using default configuration file, which is /etc/blts/blts-alsa-core.cnf

By default the test results are printed to terminal and also to /var/log/tests/blts_alsa_core.txt.

Possible arguments for blts_alsa_core_test;

Test case descriptions and execution commands:

The test cases are:

• ALSA presence check

* checks needed /dev/snd* entries and modules

* $ blts-alsa-core-tests -en "ALSA presence check"

• Open and close PCM devices

* opens and queries basic information from all available PCM devices

* $ blts-alsa-core-tests -en "Open and close PCM devices"

• Open and close timer

* opens and queries basic information from ALSA timer

* $ blts-alsa-core-tests -en "Open and close timer"

• Open and close controls

* opens and queries basic information from control devices

* $ blts-alsa-core-tests -en "Open and close controls"

• Open and close hwdeps

* opens and queries basic information from hw dependency -devices

* $ blts-alsa-core-tests -en "Open and close hwdeps"

• Enumerate control elements

* queries information of all control elements and their current settings from all control devices

* $ blts-alsa-core-tests -en "Enumerate control elements"

• Power management

* sets and queries power state from all devices

* $ blts-alsa-core-tests -en "Power management"

• Enumerate devices with control interface

* Queries information about all pcm, hw dep and rawmidi devices from control device

* $ blts-alsa-core-tests -en "Enumerate devices with control interface"

• Add and remove control element

* Creates, replaces and removes user control element. Tests also element lock/unlock

* $ blts-alsa-core-tests -en "Add and remove control element"

Rest of the test cases are generated from given configuration file, see next section.

Configuration

Configuration file defines ALSA mixer (control) settings and used playback and recording parameters. These settings depend on platform.

Configuration file example (Intel HDA based soundcard);

[defaults]
   [control]
      card 0
      set "Master Playback Volume" max
      set "PCM Playback Volume" max
      set "Master Playback Switch" off
      set "Headphone Playback Switch" off
      set "Front Playback Switch" off
      set "Capture Switch" off
      set "IEC958 Playback Switch" off
      set "IEC958 Default PCM Playback Switch" off
   [end_control]
[end_defaults]

[testset]
   description "front headphone"
   [control]
      card 0
      set "Master Playback Volume" max
      set "PCM Playback Volume" max
      set "Master Playback Switch" on
      set "Headphone Playback Switch" on
      set "Front Playback Switch" on
   [end_control]

   [playback]
      card 0
      device 0
      rates 44100 96000 192000
      formats S16_LE
      channels 2
      access INTERLEAVED MMAP_INTERLEAVED
      hw_resampling 1
      async SYNC
      duration 5
      freq 1000
   [end_playback]
[end_testset]

[testset]
   description "front mic with max volume"
   [control]
      card 0
      set "Input Source" "Front Mic"
      set "Capture Switch" on
      set "Capture Volume" max
      set "Front Mic Boost" min
   [end_control]

   [recording]
      card 0
      device 0
      rates 44100 96000 192000
      formats S16_LE
      channels 2
      access INTERLEAVED MMAP_INTERLEAVED
      hw_resampling 1
      duration 5
   [end_recording]
[end_testset]

The above configuration file produces following test cases:

Each [testset] can contain multiple [playback], [recording] and [control] sections. This allows simultaneous recording and playback cases, such as playback to phone's earpiece while recording from the mic. Simplified example;

[testset]
   description "playback and recording"
   [control]
   ...
   [end_control]

   [playback]
   ...
   [end_playback]

   [recording]
   ...
   [end_recording]
[end_testset]

Configuration file format

[defaults] section:

Defines default control element settings. These settings are applied before and after each test case. Defaults -section can contain only [control] section(s).

[testset] section:

Defines a set of settings for playback and/or recording tests. A configuration file can contain multiple testset sections, and settings within one section do not interfere with other testset sections. If testset section contains multiple playback/recording sections, the tests from each recording/playback section are executed in parallel.

Possible variables:

• description "<short description>": Description for the testset.

[control] section:

Defines mixer (control) settings. The settings are applied in the given order before playback or recording.

Possible variables:

• card X: Defines used soundcard. X can be from 0...available soundcards.
• set "<control element name>"|X max|min|on|off|Y: Sets given control element to given value. Control element can be defined by control element's name or id.

[playback]/[recording] section:

Defines PCM parameters for playback and recording.

Possible variables:

• card X: Used soundcard. X can be from 0...available soundcards.
• device X: Used PCM device. X can be from 0...available pcm devices.
• rates X Y Z... : Used samplerates as samples per second.
• formats X Y Z... : Used sample formats. Currently supported are:
  • S8: Signed 8-bit.
  • S16_LE: Signed 16-bit little endian.
  • S24_LE: Signed 24-bit little endian.
  • S32_LE: Signed 32-bit little endian.
• channels X Y Z... : Number of used channels.
• access X Y Z... : Used access methods. Currently supported are:
  • INTERLEAVED: Samples from all channels are interleaved into single buffer.
  • MMAP_INTERLEAVED: Same as above, but the buffer is memory mapped. For synchronous playback/recording only.
  • NONINTERLEAVED: Samples from all channels are in separate buffers. Currently for playback only.
• hw_resampling X: Use hardware resampling.
• async X Y Z... : Use synchronous or asynchronous IO method (playback only). Currently supported values are:
  • SYNC: Regular (synchronous) IO.
  • ASYNC_SIGNAL: Asynchronous IO, where the kernel tells the test when the audio hardware is prepared to receive more data.
  • ASYNC_TIMER: Asyncronous IO, where a constant stream of IO is done to the hardware, regulated by periodic timer signals.
• duration X: Duration in seconds.
• freq: Sine wave frequency (playback only).
• link X Y : Synchronize IO on this device with card X device Y. Only for async = SYNC.
• period_size: The interval between interrupts from the hardware (in frames). This affects used buffer sizes.
• volume: For playback only. In practice this defines the amplitude of generated sine wave. Value can be anything between 0 and 100.

Some of the variables allow multiple values, and the test cases are generated by simply creating all combinations from given values.

[bluetooth] section:

Defines Bluetooth audio settings. If a Bluetooth A2DP device is defined here, it will be connected for the duration of the test. Pairing a device is not supported as yet, and should be done before testing.

Note that just connecting to a device is usually not enough for sound output. In most cases platform-specific mixer settings are needed.

Possible variables:

• connect "nn:nn:nn:nn:nn:nn" : MAC of Bluetooth device supporting A2DP to connect to.
• pin "nnnn" : PIN for the device. (Pairing not implemented yet)

[tuner] section:

Defines v4l2 tuner settings. Possible variables:

• device "" : Used tuner device, for example "/dev/radio0"
• freq X : Used frequency in kHz, or;
• scan_select X : Scan for channels and select channel X. This works only with devices with hardware frequency seek capability (VIDIOC_S_HW_FREQ_SEEK).

Module Design and Architecture

The test module can be compiled to self-sufficient command line program. Both Debian and RPM packaging is also provided.

Architecture diagram

References

Change History