There are many audio codecs available on the market and each requires a driver to work with the audio class. The driver is referred as the Audio Peripheral Driver in the general audio class architecture. The amount of code necessary to port a specific audio codec to the audio class greatly depends on the codec’s complexity.
Micrium does NOT develop audio codec drivers. It is your responsibility to develop the Audio Peripheral Driver for your audio hardware. Micrium provides a template of the Audio Peripheral Driver than can be used to as a starting point for your driver. You can also read the different sections below.
General Information
An Audio Peripheral Driver template containing empty functions is provided. It is located in the folder \Micrium\Software\uC-USB-Device-V4\Class\Audio\Drivers\Template. You can start from it to write your driver.
No particular memory interface is required by the audio peripheral driver model. Therefore, the audio peripheral may use the assistance of a Direct Memory Access (DMA) controller to transfer audio data.
It is highly recommended to use a DMA implementation of the driver as it will offload the CPU and ensure better overall audio performances.
presents a typical stereo codec and how it interfaces with a microcontroller (MCU).
An audio codec will usually have two interfaces with the microcontroller:
- One interface to configure and control the audio codec.This interface could be I2C or SPI for instance.
- One interface to transfer audio data. This interface could be stereo audio I 2 S or any other serial data communication protocols.
As shown by the figure above, the audio peripheral driver may have to deal with two different peripherals of the MCU to communicate with the audio codec.
Memory Allocation
Memory allocation in the driver can be simplified by the use of memory allocation functions available from Micrium’s µC/LIB module. µC/LIB’s memory allocation functions provide allocation of memory from dedicated memory space or general purpose heap. The driver may use the pool functionality offered by µC/LIB. Memory pools use fixed-sized blocks that can be dynamically allocated and freed during application execution. Memory pools may be convenient to manage objects needed by the driver. The objects could be for instance data structures mandatory for DMA operations. For more information on using µC/LIB memory allocation functions, consult the µC/LIB documentation.
API
All audio peripheral drivers must declare different instances of the appropriate driver API structure as global variables within the source code. Each API structure is an ordered list of function pointers utilized by the audio class when device hardware services are required. Each structure will encompass some functions belonging to a category: common, Output Terminal, Feature Unit, Mixer Unit, Selector Unit and AudioStreaming (AS) interface. The API structure will then be passed to the appropriate
USBD_Audio_XX_Add()
functions. Theses different API structures offers two possibilities to handle the terminal and unit IDs management within a given codec driver function:
- either have one driver function for all terminals or units or AS interfaces. In that case, IDs must be managed.
- or one function per terminal or unit or AS. ID passed as argument of the driver function by the audio class can be ignored as there is a one-to-one relation between the function and the terminal or unit or AS.
Sample device driver API structures are shown below.
The audio peripheral driver functions can be divided into three API groups as shown in the .
Optional functions can be declared as null pointers if the audio chip does not support the associated functionality.
It is the audio peripheral driver developers’ responsibility to ensure that the required functions listed within the API are properly implemented and that the order of the functions within the API structure is correct.
Audio peripheral driver API function names may not be unique. Name clashes between audio peripheral drivers are avoided by never globally prototyping device driver functions and ensuring that all references to functions within the driver are obtained by pointers within the API structure. The developer may arbitrarily name the functions within the source file so long as the API structure is properly declared. The user application should never need to call API functions. Unless special care is taken, calling device driver functions may lead to unpredictable results due to reentrancy.
The details of each audio peripheral driver API function are described in the Audio Peripheral Driver API Reference.
Using Audio Processing Stream Functions
The audio peripheral driver has access to stream API offered by the Audio Processing module presented in . Basically, this stream API allows the audio peripheral driver to get buffers to transfer audio data to/from an audio codec or any other types of audio chip.
In order to better understand the use of this stream API, we will consider the typical audio stereo codec configuration shown by . Moreover, a DMA controller used by the I2S controller will be assumed.
summarizes the use of stream functions for a playback stream. Please refer to
as a complement to know what is happening in the Audio Processing module.
summarizes the use of stream functions for a record stream. Please refer to
as a complement to know that is happening in the Audio Processing module.
Statistics
As described in the section Audio Statistics, the audio class offered some stream statistics that may be useful during your development. An audio statistics structure (
USBD_AUDIO_STAT
) specific to each AS interface can be retrieved by the application and consulted during debugging. describes all the fields of
USBD_AUDIO_STAT. Among them, there are four interesting for the driver:
AudioDrv_Playback_DMA_NbrXferCmplAudioDrv_Playback_DMA_NbrSilenceBufAudioDrv_Record_DMA_NbrXferCmplAudioDrv_Record_DMA_NbrDummyBuf
You can use the macro AUDIO_DRV_STAT_INC() by specifying an AS handle and the name of the field to update statistics. shows an example of
AUDIO_DRV_STAT_INC() usage.