Focus on MCU Peripherals: USB Audio Bridge Simplifies Embedded Multimedia Designs

Now that the humble universal serial bus (USB) has become the de facto interface for virtually every type of consumer gear, there is growing interest in applying its capabilities to audio interfaces. In this article, we will explore a new category of USB bridge devices emerging that can handle many of the details required to support Audio Devices Class applications in hardware. As we will demonstrate, USB’s ample bandwidth, ease of use, and simple control structure make it a natural choice for exchanging and controlling digital high-quality audio streams.

While USB audio is simple from the consumer’s viewpoint, it’s not quite as easy on the other side of the connector. This is in large part because the USB protocol stack is surprisingly complex, capable of supporting a number of distinctly different types of applications, formally known as USB Classes. This includes the Audio Devices Class, which defines a robust standardized mechanism for transporting audio over USB. Extracting audio data from a USB port for distribution, storage, or further processing by an application’s MCU often requires a firm grasp of the details of USB’s protocol layer (To learn more about the USB protocol itself, see the TechZone article “Tips, Tricks for Using USB in Embedded Applications - Part I”). In addition to the complexities of the protocol itself, other audio-related issues, such as synchronization of data streams and programming codec and digital-to-analog converter (DAC) configurations, can challenge even the most experienced embedded and audio designers.

To address these issues, devices like Silicon Labs’ CP2114 audio bridge supports the synchronization, stream management, and other tasks that would normally require a significant software development effort. In this article, we will also look at a few ways USB audio bridges provide a novel standard audio configuration interface and methods to synchronize audio data streams in a low-cost, highly integrated single-chip solution.

One of the biggest challenges involved with streaming audio over USB is the synchronization of data streams from the host (source) to the device (sink). Although USB was originally developed as a simple interface for connecting keyboards, mice and printers, its protocol specification also includes a robust synchronization scheme for “isochronous transfers.” The Audio Device Class definition employs this scheme to transport audio data reliably over the bus. However, the implementation of this mechanism is not a trivial task, and previous implementations have usually been built around relatively powerful embedded systems that included complex data rate converters or expensive phase-locked loops (PLLs) to support the clock accuracy requirements.

As an example, a system with a sampling rate of 48 kHz, the host processor transmits a frame containing 48 analog output samples every millisecond. The sink (receiving device) must buffer the audio output data so it can be sent to the DAC, one sample at a time. Even a small clock mismatch between host and device can result in an over-run or under-run condition. The USB specification defines several methods for accommodating host/device clock mismatch.

Table 1 lists the various modes that govern the operation of USB sources and sinks. (Keep in mind that for audio-out operations, the host is the source and the device is the sink. For audio-in operations, the device is the source and the host is the sink.)

Asynchronous mode transfers

Asynchronous operations are employed when the sink device does not have PLL hardware to synchronize with the host clock. In this mode, it is virtually certain there will be a frequency mismatch which causes it to process the audio data sent by the source either too slowly or too quickly. To accommodate this source/sink clock mismatch, the sink provides explicit feedback about to the source which it uses to adjust its sampling rate and the rate at which it sends samples to the sink (Figure 1).

Figure 2 illustrates an asynchronous transfer mechanism using a buffered system operating at a nominal 48 kHz sampling rate. Initially, the host begins streaming data at 48 samples for each USB start-of-frame (SOF) operation, which occur each millisecond. If the clock mismatch causes the sink device’s buffer to approach a full or empty condition, the device can request the host to send more (49) or fewer (47) samples each time to keep the buffer from experiencing overrun or underrun conditions. Hardware logic which supports this signaling mechanism is implemented in Silicon Labs’ CP2114 USB-to-I2S digital audio bridge device, allowing it to support the Audio Device Class without any additional software development.

Figure 2: Asynchronous mode operation requires explicit feedback from the receive buffer to prevent under-flow or over-flow conditions.

Synchronous transfers

For synchronous operation, the source and the sink use implicit feedback, and both devices’ clocks are locked to the USB SOF. The sink device must synchronize with the USB SOF (Figure 3).

Figure 3: Synchronous mode operation uses a common clock to insure the source only supplies as many data packets as the sink device can handle.

A simple yet robust implementation of synchronous mode can be accomplished by a closed-loop control that can correct any mismatches between the USB SOF and the internal oscillator of the sink device. This implementation is shown in Figure 4.

Figure 4: A closed-loop control scheme to support Synchronous Mode operation based on an internal oscillator.

The USB SOF that is sent by the host every millisecond is used to calibrate the internal oscillator. For this method to work properly, the internal oscillator of the sink device must be adjustable through a calibration register that can increase or decrease the internal oscillator frequency in very small steps. The CP2114 digital audio bridge’s internal oscillator includes a digitally-controlled dynamic trim mechanism which has sufficient precision to meet these requirements. The CP2114 enables the developer to select between synchronous mode and the asynchronous mode which is now supported by all popular platforms (including Windows, Linux, Mac OS, and iOS for the Apple iPad).

Codec/DAC configuration interface “non”-standards

Thanks to the wide range of codec and DAC components available from many manufacturers, designers can choose devices which deliver the performance and features they require. Unfortunately however, there is no standard or protocol for configuring the capabilities of their devices. As a result, each manufacturer has its own unique device configuration procedures, a realty which usually adds to the complexity of the software that developers must create in order to support multiple codec/DAC platforms.

One solution to this problem is to equip the USB bridge with a “shim mechanism” that presents a standard codec/DAC configuration interface to the host system. A standard set of register locations allows a developer to configure the typical capabilities found in most codecs and DACs without knowing much more than the model number of the device being used. Besides simplifying software development, this capability makes it easy to evaluate various codec/DAC products, or transition an existing design to different components. For this reason, the CP2114 audio bridge includes a standard configuration interface mechanism which supports a wide range of codecs/DACs.

As shown in Figure 5, the CP2114 bridge device’s standardized programming interface addresses the most common capabilities found in all codecs and DACs, including DAC register sizes, audio format, volume control and audio clock ratio. In addition, the interface offers open fields for custom programming and an abstraction layer encapsulating the most typical configuration capabilities in an easy-to-understand format.

Figure 5: Block diagram of the CP2114.

Once the developer is familiar with this interface, switching between codec and DAC devices becomes a simple task. Table 2 lists a portion of the CP2114 standard audio configuration programming interface.

Table 2: A sample of the functions addressed by the CP2114 bridge device’s standard programming interface.

The device’s USB port doubles as a control/configuration interface for all of its features, including DAC/codec set up. All configuration values are stored in EPROM and can be altered by host at any time, allowing dynamic updates to the codec/DAC’s configuration values.

Conclusions

Major design issues, such as synchronization of audio data streams and codec/DAC configurations, can challenge even the most expert embedded and audio designers. Next-generation digital audio bridge solutions, such as the CP2114 device, minimize this complexity by supporting a wide range of codecs and DACs through a standard configuration interface, support asynchronous and synchronous modes of operation with minimal external components, and eliminate the need for external components, such as crystal oscillators and EEPROM.

Further reading

1. The USB audio class specification is available to the public from the USB Implementers Forum
2. Microcontroller TechZone article: Audio Coding and Compression for Microcontrollers – Publitek European Editors
3. Microcontroller TechZone article: Choosing the Right MCU for Your Audio Application — Lee H. Goldberg
4. Microcontroller TechZone article: Choosing an MCU for Audio Capture/Playback — Maury Wright