Solutions to Support Audio-Video Applications with Advanced Audio Codecs
By proper reconfiguration of the digital filters, sample rate conversion and flexible clock frequency choices, it is possible to support a wide range of audio-video applications with advanced audio codecs. There are several solutions for these applications that help designers understand the trade-offs needed to minimize the costs of their SoCs.
Phase-Locked Loop (PLL) for the Audio Clock
Many applications such as portable products cannot have dedicated crystal oscillators for the audio codec, due to its space and/or cost limitations. The audio codec must be able to support the different audio rates from the available host master clock, which is often the USB clock operating at 12 MHz or a multiple of it. In which case, a phase-locked loop (PLL) can be used to generate the required audio clocks. But this PLL is relatively complex due to the very fine frequency resolution required for supporting all the frequency combinations, while at the same time providing a low-jitter output clock for performance. Other solutions not requiring a PLL would be preferable.
An alternative solution is the PLL-less technique of re-using the USB clock and avoiding adding a dedicated PLL for audio. USB is a very popular interface and almost universally present in any application. Either 12-MHz or 24-MHz clocks are used and have relatively low jitter, which is an important requirement for audio. A USB clock of 12 MHz can support the 48-kS/s audio rate because it is an integer multiple (12,000 = 250 x 48). To use it, the filters sample rate conversion needs to be reconfigured from the nominal 256X to 250X.
The 44.1 kS/s audio rate, however, can only be approximately generated. Using a sample rate conversion of 272X, the audio clock can be approximated to 44.1176 kS/s, which is slightly different from the nominal. But the difference is quite small and hardly noticeable. In effect, it is just a 0.04% change in pitch. To put that in perspective, it is 100 times less than a semitone. Another way to appreciate the effect of the clock approximation is in the duration of a song: 0.04% faster playback corresponds to a 3-minute song completing 10 milliseconds (ms) earlier.
A/V multimedia equipment produces data streams that are both video and audio. Examples are DVD players and MPEG media readers. The sampling rates are independent for video and audio. Video uses 27 MHz clocks or multiples. The audio clocks must be derived from 27 MHz and all standards based on 44.1 kS/s, 48 kS/s and 8 kS/s must be supported.
These audio clocks are best generated with a PLL having as reference a division of the 27 MHz video clock. Due to the synchronism between audio and video data, the PLL-less technique is not applicable because it would change the audio playback cadence relative to the video. This would cause the audio to get misaligned with the video image, causing loss of lip-sync.
Synchronization with the Source Clock
There are applications where the source of data is remote to the equipment. An example of this would be TV broadcasts (cable, terrestrial or satellite), HDMI cables and web streaming. In these cases, the audio and video clocks must be synchronized with the source clocks.
To illustrate this situation, let's consider a digital TV transmission (as illustrated in Figure 4). The data transmitted by the TV station is synchronized to a reference 27-MHz clock at the transmitter site. Due to tolerances on the transmitter crystal oscillator and Doppler effects during propagation, the frequency received by the TV antenna at the receiver site may vary. In order to ensure synchronization of the data, a coded time stamp (CTS) is included in the transmitter MPEG data signal. The CTS allows synchronization of the video and audio packets for an accurate lip-sync during playback.
Since the received frequency varies over time, data may be arriving slower or faster, producing clock drifts relative to the receiver's own 27-MHz clock. This variation in data flow will result in either too much or too little data arriving at the receiver to be processed. For video data, this drift is not significant and can be corrected by dropping or repeating frames. While the video is decoded, the receiver is constantly comparing the time stamp received from the transmitter with that of the decoded video.
When too much data accumulates in the decoder (i.e., the receiver's 27-MHz clock is slower than the transmitter clock), a frame is dropped. When too little data is available for processing, a frame is repeated. Since frames are either dropped or repeated so infrequently, the effect is not noticeable to the viewer.
Audio data must also be synchronized with the transmitter clock. The audio clocks must be derived from the same 27 MHz video clock and all standards must be supported. But dropping/repeating samples are unacceptable in audio because it would be highly perceptible to our ear. The solution is to have a PLL to generate the audio clock and use the time stamp information to lock the PLL to the received sampling data.
Figure 4: Block diagram of a solution with a PLL that uses time stamp information from the video decoder to synchronize the audio clock
For more information on Synopsys' DesignWare Audio IP solutions, please visit www.synopsys.com/audio.
About the author:
Carlos Azeredo-Leme is a senior staff engineer for the DesignWare Analog IP at Synopsys since 2009. Prior to joining Synopsys, he was co-founder and member of the Board of Directors of Chipidea Microelectronics in 1993, where he held the position of Chief Technical Officer. There, he was responsible for complete mixed-signal solutions, analog front-ends and RF. He worked in the areas of audio, power management, cellular and wireless communications and RF transceivers. Since 1994 he holds a position as Teacher at the Technical University of Lisbon (UTL-IST) in Portugal. His research interests are in analog and mixed-signal design, focusing on low-power and low-voltage. Carlos holds an MSEE from Technical University of Lisbon (UTL-IST) in Portugal and a Ph.D. from ETH-Zurich in Switzerland. Carlos can be reached at email@example.com.
For more articles like this and others related to audio design, visit Audio Designline and/or subscribe to the monthly Audio newsletter (free registration).