Audio Class Architecture

Figure - General Architecture between a Host and Micrium's Audio Class shows the general architecture between the host and the Micrium audio class.

Figure - General Architecture between a Host and Micrium's Audio Class

General Architecture between a Host and Micrium's Audio Class

The audio class is composed of three modules. The Audio Transport module is responsible for the initialization of the class done by the device application. It provides the class-specific descriptors needed by the host during the enumeration and also performs the class-specific requests decoding sent via control endpoints. The Audio Processing module is in charge of the the class-specific requests execution and the audio data streams communication done through isochronous endpoints. The Audio OS module provides specific OS services needed by the audio data streams communication. This module does not assume a particular OS. By default, Micriµm provides the Audio OS layer for µC/OS-II and µC/OS-III. If you need to port the audio class to your own OS, refer to Porting the Audio Class to an RTOS for more details about the Audio OS module.

Audio Peripheral Driver

This module communicates with the Audio Processing module to perform the final action associated to a class request (e.g. muting, changing the volume value) and to transfer audio data to/from the audio peripherals. Micrium provides a template of the Audio Peripheral Driver than can be used to start writing your driver for your audio codec. You can refer to Audio Peripheral Driver Guide for more details about how to write your codec driver. Micrium does NOT develop audio codec drivers. It is your responsibility to develop an Audio Peripheral Driver for your audio hardware.

The host can use various class-specific requests to configure and monitor terminals, units and streams. Any class-specific requests are sent through the control endpoints. Figure - Class-Specific Requests Management shows the class-specific requests management done by the audio class:

Figure - Class-Specific Requests Management

The Audio Transport module receives the class-specific request and does the first pass of decoding, that is determining the recipient: unit or terminal associated to the AudioControl interface or AudioStreaming interface or endpoint. Once the recipient identified, the Audio Processing is called and the control selector (that is the Control described in Table - Units and Terminals Description, Controls and Requests and Table - AudioStreaming Interface Controls and Requests) will be decoded. Note that a second recipient decoding among units (Feature, Mixer or Selector) and terminals (Input or Output) will be done. Once the control selector recognized, the request type supported by the control is verified. If the request is supported, the action associated is executed by the Audio Processing or the Audio Peripheral Driver if it requires access to the codec to get or set the information. At any steps, if something wrong is detected, the decoding process is aborted and the control transfer will be stalled by the device stack.