Soundbar Design From Start To Finish: From Specification To Selection

Fig 1. In a typical audio signal chain, analog inputs must first pass through an ADC before heading to the processor, whereas digital inputs can bypass the converter and be sent straight to processing.

Fig 2. Front-end designs in the topologies of typical analog front ends for soundbars can vary wildly. But in terms of standard features and layout, this is what you can normally expect.

Consumer home audio is getting simpler, as a single soundbar can replicate the audio experience of other multi-speaker installations. These devices aren’t difficult to design either. Once you have your specifications (see “Soundbar Design From Start To Finish: Setting Design Specifications” at electronicdesign.com), it’s time to select your parts. First, we’ll break our requirements down in terms of the audio signal chain (Fig. 1).

Sources: Analog Inputs

In the real world, with analog sources like TVs, Blu-ray players, set-top boxes, and gaming consoles, most if not all manufacturers stick to a maximum input level of 2 V rms, or about 5.6 V p-p. Anyone with a lot of design experience will tell you this standard is a pain to deal with, as most classic audio converters run from a +5-V analog supply.

When considering a front end for our analog-to-digital converter (ADC) (Fig. 2), a few things must be done:

• Attenuate: We need to bring a 5.6-V p-p signal down to one that is small enough to max out the ADC only when the signal is at its highest level. This will ensure that we don’t clip the input stage, but at the same time, take advantage of the entire dynamic range of the ADC.
• DC block: Most ADCs aren’t split-supply, meaning a ground-biased input must be ac coupled to the ADC’s input (that’s floating at mid-rail). Most folks will use a dc blocking capacitor at this point. Don’t forget that depending on the input impedance of the ADC or buffer, you’re potentially creating a high pass filter. Select the capacitance carefully. Capacitor selection should be based on the input impedance of the buffer/ADC, maximum voltage swing, size of the capacitor, and chemistry type.
• Protect: Electrostatic discharge protection (ESD) diodes are critical at this point in the design. As a connection directly into an ADC (or a buffer) from the outside world, we must assume that the users are walking on carpet, with rubber-soled shoes on, and are buzzing with static electricity. Static kills poor little ICs. We can protect them with external ESD protection diodes.
• Shield: Electromagnetic interference (EMI) is something that most people won’t even notice during development, then take their product to UL certification labs (required to resell a product at the big resale stores) and fail miserably, with EMI spouting out of the product, even on input connectors. A simple ferrite bead near the input and output connectors can make a world of difference.

Sources: Digital Inputs

There are many types of digital audio interfaces available. The most common, Sony Philips Digital InterFace (S/PDIF), comes in three physical formats: optical, coaxial, and Differential (a professional audio standard known as AES/EBU that is slightly different, but still compatible with other S/PDIF solutions).

Originally, S/PDIF was only used to transmit Stereo PCM data at 44.1 kHz or 48 kHz. That quickly got extended to 192 kHz. Today, the S/PDIF output from a product also can be in a specially encoded format. A typical example of this is Dolby Digital AC-3, a multichannel format that essentially allows 5.1 channels of audio to be transmitted over a single wire.

All that coolness comes with a price, however. Any specially encoded data will also require a decoder on the other end. This typically takes the form of a dedicated decoder DSP of some kind. Regular PCM data generally doesn’t require a data decoder, only a basic S/PDIF decoder.

To clarify, a standard S/PDIF decoder such as the Texas Instruments DIR9001 takes stereo PCM S/PDIF and outputs an industry-standard I2S. Most Dolby Digital AC-3 decoder ICs can accept encoded data received in I2S format, recognize that data as encoded, and then decode it. The difficulty starts when we begin to consider the effects of different sample rates and other factors.

In a standard consumer setup, digital audio transmitted over S/PDIF is sent in one direction. In other words, there is no feedback from the receiver to the transmitter, no screams of “Hey, I don’t support that frequency!” or “Hey, not that format please!” This problem really starts to rear its ugly head when you switch sample rates on the fly. DVDs can do this easily. Some content will play back at 44.1 kHz and then suddenly jump to 48 kHz when you jump to a different chapter or content.

This has a direct influence on any processing you have running in your system, as most DSPs are slaves to incoming data. Any filters you have set up will have coefficients (settings) configured to work at specific sample rates (e.g., 44.1 kHz). If you suddenly bring in a 96-kHz signal, then all the settings, such as a lovely 80-Hz high pass filter, will suddenly be working at a different frequency. (Frequencies in digital processing are typically referenced as a fixed division of the sample frequency.)

There are two ways to deal with switching sample rates in a receiver: sample rate conversion and bank switching.

Sample rate converters (SRCs) have been on the market for a number of years now. Assuming you’re dealing with a proper I2S stream (i.e., not encoded with AC-3, etc.), they can effectively provide a black-box interface that will perform a conversion between any input (32, 44.1, 48, 88.2, 96, 192 kHz) to 48 kHz or any other system sample frequency. They do, however, add some system cost, and this is where the bank switching option can come in handy.

In bank switching technology, the appropriate coefficients for each sampling frequency are stored in memory. As the sampling frequency changes, new coefficients are loaded into the program. In a system where the designer can be certain that only specific sampling frequencies will be used, this is a great way to keep costs down.

The selection between SRC and a bank switching system requires careful considerations regarding input data expectations and budget. An SRC will almost always add more cost than a bank switching system, though an SRC will be ready for virtually any input data rate.  

Sources: Computer Based

In the consumer audio space, computer interfaces that require users to install software drivers are severely frowned upon. Developers using USB should always try and find class-compliant USB audio devices. In the real world, this means that upon connection to a PC/Mac/Linux system, they will be recognized and in many cases set as the default audio port.

Such functionality is wonderful if you’re making PC speakers or an audio dock, which are well-known plug-and-play devices. However, many devices also require the ability to download and stream content, in which case they may need drivers. It’s best to offer two levels of service in this case. When first connected, the product simply streams using the USB audio device, and after additional drivers have been added, additional product functionality is enabled.

For audio-only streaming, the PCM2xxx audio codecs are excellent and easy to use. If you require additional functionality, TI offers a wide range of OMAP and Stellaris ARM devices offering programmable USB interfaces that can act as system controllers, processors, and USB interfaces for your audio product.

Sources: Apple Devices

With customers demanding more and more functionality and quality in their audio products, along with increased cell-phone interference, the need to move to digital audio interfaces is slowly working its way into the market.

TI’s Stellaris range of ARM devices offers a solution for interfacing to Apple devices. If you’d like to develop accessories that are compatible with Apple devices, and to find out more about the Made for iPod (MFI) Licensing program, visit http://developer.apple.com/MFI.

Next time, we’ll start looking at the other parts of the system: the audio processor, the system host controller, and I/O ports—and we still won’t be done after that!