Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

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

Panel
borderWidth0
titleFigure - General Architecture between a Host and Micrium's Audio Class

General Architecture between a Host and Micrium's Audio ClassImage Added


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.

...

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.  shows Figure - Class-Specific Requests Management shows the class-specific requests management done by the audio class:

Anchor
Figure - Class-Specific Requests Management
Figure - Class-Specific Requests Management

Panel
borderWidth0
titleFigure - Class-Specific Requests Management

Image Added


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.

...