AN295
USB A
U D I O
C
L A S S
T
U T O R I A L
1. Introduction
Isochronous data transfers can be used by universal serial bus (USB) devices designed to transfer data to or from
a host at a constant rate. Systems streaming audio employ isochronous transfers to transmit audio signals in real-
time. Silicon Laboratories microcontrollers’ robust USB peripheral supports isochronous transfers, and each
family’s assortment of additional high quality peripherals make them excellent single-chip solutions for USB-based
embedded system designs.
This document contains the following:
A USB protocol overview concentrating on isochronous transfers
A Firmware Template that provides a starting point for custom USB Audio Class device firmware
An example system illustrating requirements and operation of USB Audio Class devices
1.1. Overview
The first section of this application note discusses the key points of the USB specification that must be followed by
all USB devices, as well as isochronous transfer protocol requirements. The second section introduces the
Firmware Template for USB Audio Class devices. The last section discusses an example USB Audio Class device.
The example shows an Audio Class device that streams a sine wave to the host.
2. USB, Isochronous Transfers, and the Audio Class
The USB communications protocol outlines specifications for a reliable and fast system of data transfer between a
peripheral and a host such as a PC. The protocol defines four different data transfer types (bulk, interrupt, control,
and isochronous), each with unique characteristics and uses. USB device classes employ transfer types that suit
the needs of particular applications and systems. The USB Audio class uses the isochronous transfer type to
stream audio across a USB link.
2.1. USB Operational Overview
When a USB device connects to a USB port, the host controlling the port retrieves information about the
capabilities of a device through control transfers during a process called enumeration. Devices format this
information into descriptors. USB Specification documents define the structure of descriptors.
USB devices send and receive data through endpoints. All USB devices must have one control endpoint through
which all enumeration data travels. Descriptors read during enumeration describe the device’s other endpoints,
their data flow direction, maximum packet size, transfer type, and other characteristics used after enumeration
successfully completes.
After examining the device’s descriptors, the host determines how to communicate with the device. If the host can
allocate resources (data bandwidth, power) requested by the device, then enumeration completes successfully and
the host begins operations communication with the device. During operations communications, transfer methods
such as those using isochronous endpoint transfers take place.
2.2. Isochronous Transfer Characteristics
The host guarantees bandwidth to isochronous endpoints. This bandwidth guarantee is a feature unique to
isochronous endpoints. The amount of bandwidth allocated to a particular isochronous endpoint is determined by
information requested by that endpoint’s descriptor. Data transfers take place inside USB data frames. For Full
Speed USB devices such as the Silicon Laboratories C8051F32x, a data frame spans 1 millisecond. A device can
be configured to transmit as few as 1 byte per frame or as many as 1023 bytes per frame.
Rev. 0.1 6/06
Copyright © 2006 by Silicon Laboratories
AN295
AN295
The USB specification defines IN and OUT designations from the perspective of the host, meaning that IN
endpoints transmit data to the host and OUT endpoints receive data from the host. During every 1 millisecond
interval during communications operation, the host signals isochronous IN endpoints to transmit bytes to the host,
and signals isochronous OUT endpoints to receive bytes from the host.
Unlike other transfer types, isochronous transfers have no hardware-controlled handshaking or error-checking
ability, so errors may occur occasionally. Systems must be able to recover from occasional errors without the help
of hardware.
2.3. The USB Audio Class
The USB Specification documents group devices with similar capabilities into device classes. Device Class
specifications require that devices share many characteristics in common, while allowing for customization and
innovation. The “Universal Serial Bus Device Class Definition for Audio Devices” describes how audio devices
must perform, how class-specific Descriptors must be defined, etc. Because host operating systems typically
contain device drivers for defined USB classes, designers of these devices do not need spend resources on
developing their own device drivers.
2.4. Creating an Audio Class Device With Silicon Laboratories Microcontrollers
The creation of a USB Audio Class device requires two steps:
Descriptors retrieved by the host must be configured to describe a device as following the specifications for
Audio Class devices.
Device firmware must configure the microcontroller to enable USB isochronous transfers.
The next section of this application note describes a Firmware Template that accomplishes the above two steps.
The section following it provides an example of a USB Audio Class device.
2
Rev. 0.1
AN295
3. Firmware Template
The firmware template included with this application note allows users to create custom USB Audio Devices. The
template contains all descriptors and routines needed to create a composite device with an audio interface and an
HID interface.
The firmware template provides the following:
Descriptors defining a USB device with two Audio Interfaces, one for full bandwidth and an alternate zero
bandwidth interface
Descriptors defining an HID interface with one IN endpoint, one OUT endpoint, and function stubs for Get
Report and Set Report requests
Low-level USB routines to handle all standard requests and interrupts for the Audio class and the HID Class
The following subsections show how the Firmware Template can be modified to suit a custom audio streaming
system.
3.1. Descriptors
Only a few items in the descriptors contained in the Firmware Template will need to be changed to create a custom
system. Please read the section Tone Generator Reference Design for a more detailed explanation of the
F320_USB_Descriptors.c
file and how modifications to the descriptors affect the capabilities of the device.
The following is a checklist of descriptor items that may need to be modified in order to accurately describe the
characteristics of a custom system:
The VID and PID items located in the Device Descriptor (these can be changed in
F320_USB_Descriptor.h)
String index values (iProduct,
iVendor, iInterface,
etc.), depending on what strings the custom
application defines
wTerminalType,
which specifies type of Audio Class device defined by the descriptor (Terminal Type values
can be found in the document titled “USB Device Class Definition for Terminal Types”)
bNrChannels,
which commonly describes a stereo (2-channel) terminal or a mono (1-channel) terminal
wChannelConfig,
which gives information on orientation of each channel (values can be found in the “USB
Device Class Definition for Audio Devices”)
Master and channel controls, depending on what features the Audio Device supports (values can be found in
the “USB Device Class Definition for Audio Devices”)
Audio Format Descriptor – the template contains a descriptor structure for a Type I format audio stream. Using
other types of streams (defined in the document titled “USB Device Class Definition for Audio Data Formats”)
may alter the size and structure of this descriptor)
Contents of the default Type I Audio Descriptor – these items describe the size of each sample, the sampling
rate, etc. and must be changed to suit a custom system’s specifications
bEndpointAddress
for the isochronous endpoint, depending on whether the custom application streams
audio into the host or out of the host
HID Report Descriptor, depending on the system’s report structure requirements (see AN249 for a more
detailed discussion)
The Report Descriptor’s size, stored as
HID_REPORT_SIZE
in
F320_USB_Descriptor.h,
to match the
custom size of the Report Descriptor
Rev. 0.1
3
AN295
3.2. Endpoint 3 Handler
The descriptors configure Endpoint 3 to be the Audio Class’s isochronous endpoint. The USB Interrupt Service
Routine ISR will vector to the Endpoint 3 handler when it receives a token packet from the host requesting a
transfer with that endpoint. The contents of this handler are highly system specific, but will most likely perform one
or more of the following tasks:
For an IN stream from device to host, the handler places data on the Endpoint 3 FIFO.
For an OUT stream from host to device, the handler processes FIFO data received from the host.
The handler updates global variables used in other custom system-specific operations.
When large amounts of data must be processed inside the handler, fast ISR execution speed becomes crucial to
system stability. If the device has not finished servicing one ISR call when the host calls for the device to begin the
next ISR call, audio packets might be lost. In these cases, users should consider writing code for the USB ISR and
often-executed routines in embedded 8051 assembler language. At slower data rates, such as the rate used in the
Tone Generator example, the handler can be written in C.
3.3. HID Interface
For communications across the HID Interface, users must make a number of modifications to Firmware Template
files. The HID Specification requires that all HID data be formatted into reports, which are data structures defined in
one of the HID’s descriptors. Reports can travel across the control endpoint or the interrupt endpoints, Endpoint 1
and Endpoint 2. The Firmware Template defines Endpoint 1 as an IN endpoint and Endpoint 2 as an OUT endpoint.
The Control Endpoint sends and receives HID reports through the standard requests Set Report and Get Report,
respectively.
Making the following modifications will enable HID data traffic:
In F3xx_USB_Common.c, write endpoint handler routines that process HID IN or OUT endpoint traffic
In F3xx_USB_Common.c, add calls to appropriate endpoint handlers in the USB Interrupt Service Routine.
In
F3xx_USB_Class_Specific_Requests.c, Get_Report()
contains a switch statement that need to be
populated with a case for each potentially outgoing report, designated by its unique Report ID.
In
F3xx_USB_Class_Specific_Requests.c, Set_Report()
points data pointers to a buffer where
incoming data is stored, and
Handle_Set_Report()
contains a switch statement that need to be populated
with a case for each potentially incoming report.
4
Rev. 0.1
AN295
4. Tone Generator Reference Design
The Tone Generator reference design uses the Firmware Template to create a simple USB Audio Class Device
that sends a single tone across an audio stream to a host-side PC application. This design generates its audio
signal by a wave table stored in the microcontroller’s nonvolatile memory. The system outputs a stereo sine wave
across an isochronous endpoint.
4.1. Descriptors
The next subsections discuss how each of the descriptors of the firmware system defines the device as an Audio
Class device with an isochronous endpoint. Table 1 gives a summary of each descriptor defined in the firmware.
Indentations along the left side of the table indicate descriptors subordinate to descriptors listed before the
indentation.
Table 1. Descriptor Summary
Device Descriptor
Contains general information about the device that applies to all
device configurations. A USB device can have only one Device
Descriptor
Describes a collection of interfaces (paths for data traffic). Call
to retrieve this descriptor returns all subordinate descriptors (as
seen below). This configuration contains 4 interfaces.
Describes audio interface from perspective of data paths and
controls. Subordinate descriptors follow.
Lists the different data paths (terminals) and their capabilities
(units).
Describes audio control data traveling from host to device.
Lists controls (volume, muting, etc.) associated with the above
terminal.
Describes the audio data traveling out of the device and into the
host.
Describes the audio stream that uses an isochronous endpoint
to transfer the audio.
Required alternate interface that does not use the isochronous
endpoint. This interface is chosen by the host when lack of
bandwidth prevents the use of the isochronous endpoint.
Describes the audio stream type in greater detail.
Gives specific specifications of audio stream.
Assigns an endpoint to be the audio stream’s isochronous end-
point.
Gives Audio Class-specific characteristics of the isochronous
endpoint.
Defines the HID interface.
Describes the capabilities of the HID interface.
Assigns an endpoint to be an IN interrupt endpoint used by the
HID interface.
Assigns an endpoint to be an OUT interrupt endpoint used by
the HID interface.
Defines all HID data structures.
Configuration Descriptor
Audio Control Interface Descriptor
Interface Header Audio Class Descriptor
Input Terminal Audio Class Descriptor
Feature Unit Audio Class Descriptor
Output Terminal Audio Class Descriptor
Audio Stream Interface Descriptor
Alternate Audio Interface Descriptor
Audio Stream Audio Class Descriptor
Format Type Audio Descriptor
Isochronous Endpoint Descriptor
Isochronous Endpoint Audio Class
Descriptor
HID Interface Descriptor
HID Descriptor
HID IN Endpoint Descriptor
HID OUT Endpoint Descriptor
Report Descriptor
Rev. 0.1
5
京公网安备 11010802033920号
EEWORLD
