Soundbar Design From Start To Finish: Choosing And Controlling An Audio Processing Scheme
Fig 1. A simple GPIO expander can be used to increase the amount of ports without the need for interrupts.
Fig 2. The Value Soundbar Reference Design can be expanded with headers so a wireless module can communicate with a wireless subwoofer.
Imagine the audio setup in your ideal home entertainment center. Do you want speakers and wires all over your living room, or would you prefer a single, intelligent product that can emulate the audio experience of other multi-speaker installations? You probably would like that single product, known as a soundbar—and you can build one yourself.
Previous articles have discussed the specs and translated them into a parts list (see “Soundbar Design From Start To Finish: Setting Design Specifications” and “Soundbar Design From Start To Finish: From Specification To Selection” at electronicdesign.com). Now, let’s talk about audio processing. Should we go analog, digital, or dedicated processing?
It all depends on the complexity of the processing required by the system. Some products require very simple audio frequency equalization (EQ) to compensate for poor speaker enclosures or drivers (speakers themselves), while others need HD decoders and multiple channels of special post-decode processing.
For simple speaker system EQ-ing, (single cutoff frequency, or maybe two), designers may be better off rolling up their analog design sleeves and getting in there with a couple of passives. But for virtually any other kind of audio processing, with anything more than EQ, digital processing really is the way to go.
The Digital Solution
Many DSPs on the market today include graphic tools that allow designers to drag and drop their audio processing signal chain. This is an excellent solution for those requiring simplicity and speed in their design, along with complex audio processing and branded algorithms from the likes of SRS, Dolby, and Waves.
Digital solutions allow multiple effects to be created serially, all on-chip and tweakable with a simple mouse click. They also allow dynamic effects (such as dynamic range control, or “auto-volume” as some may know it) to be created without expensive analog alternatives, like voltage-controlled amplifiers (VCAs).
Texas Instruments offers a wide range of solutions like this, from the DA7xx discrete audio DSPs to the TAS3xxx multichannel audio processors, all the way down to the baby of the family, the PCM3070, a stereo codec with integrated DSP.
Processing requirements drive the selection of dedicated processors, as opposed to processors with integrated codecs (or codecs with integrated processors). Typically, any mix of digital and analog on the same piece of silicon requires a compromise on both devices.
For instance, the PCM3070, with its stereo codec, provides a more than 93-dB signal-to-noise ratio (SNR) for its analog I/O. It also offers up to 110 MIPS of performance across its dual miniDSPs. Compare that with a dedicated DA7xx DSP, which doesn’t include audio converters onboard, and the device racks up an over 2400 MIPS in its DSP alone!
Selecting the best solution will be based on cost requirements (Do you really need a 2400-MIP DSP for a few bands of EQ and dynamic range control? No!) and channel I/O requirements. For example, the PCM3070 can handle up to four output channels. But if you’re driving a 5.1 system, it may not be the best solution without some clever mixing.
System Controllers
Once you’ve selected how you’re going to process the data, the next challenge is to figure out how on earth you’re going to control the processing itself and how your user is going to interface with your product. Let’s jump in the deep end and talk about the user interface itself. On our specification napkin, we decided that we should offer an on-product interface, as well as a remote control interface.
That means we need buttons (general-purpose I/O, or GPIO) and an infrared receiver for the remote, immediately requiring multiple pins of I/O on the processor. We also need to consider how we’re going to communicate with the other ICs in the system, which typically requires either I2C or SPI. That takes another two pins (minimum) on our host.
So, if we count standby, volume up, volume down, input cycle, effect one, and effect two, that’s six buttons already. If we add specific buttons for inputs, the number continues to climb.
Other inputs on the general-purpose microcontroller may include interrupts from other ICs on the board. If the sample rate of the incoming Sony/Philips Digital Interconnect Format (S/PDIF) signal is brought in on two pins, that’s another two inputs we need. Lock status from the S/PDIF input is another input pin.
Once we’ve counted all the general-purpose inputs, we need to start looking at the outputs. Outputs to consider include LEDs for user feedback, or direct control of other devices that you might require within your design: things like a “shutdown” control on the amplifier to save power, or minimized pop and click on startup, or perhaps input multiplexers, so you can select from multiple digital or analog sources.
Once you start adding up all these GPIO requirements, it’s very easy to end up with a 28-pin (or more) device. I/O expanders can reduce this somewhat, which we’ll discuss deeper in this article. But in my experience, buying one IC is always cheaper than buying multiple ICs for the same purpose, unless that one IC includes many more unused features.
When you’ve got a good handle on the number of pins you need, start thinking about the amount of RAM and storage memory you need (either as flash or external EEPROM). In some cases, it may be more efficient to buy a host microcontroller with a ton of flash memory onboard, enough to look after the housekeeping of the system, as well as the program code required by the audio DSP processor.
To give you a rough idea of the memory requirements, we found that in a typical application on the PCM3070, we can easily pack 6 kbits of code and coefficients into the device.
In addition to that, the host controller itself will require code and coefficients, especially if there’s any kind of display to be used (other than LEDs). Again, the amount of storage memory required begins to add up quickly, and sharp designers must balance the cost of buying a larger flash memory microcontroller or using an external EEPROM. Again, this is a balance between cost, size, and used/unused functionality in the processors.
As a point of reference, for our Value Soundbar Reference Design, we selected an MSP430F2131 as the host microcontroller, along with an external 16-kbit EEPROM. This gave us plenty of options in terms of having space to have multiple programs for the miniDSP, as well as having options to shrink the flash size in the MSP430, if required. It also had just enough I/O to make it worthy, all while keeping it reasonably priced.
The only expansion IC required was a simple I2C to GPIO expander, which we used to drive the multiple-LED feedback on the front panel. All these signals are outputs, which means we don’t need to drive interrupts from them. They’re slow too, making them ideal for being used offboard.
Finally, as part of a multiple stock taking unit (SKU) strategy, designers can choose whether they want or do not want the array of LEDs without changing the layout of the rest of the system significantly (Fig. 1).
The Unexpected
One of the best pieces of advice I received in my years of working on customer systems was to always design for the unexpected. It’s one thing to design defensively, where you assume your design will have to be changed if something doesn’t work. It’s another thing to try and stay one step ahead of marketing.
Marketing folks are constantly looking for ways to get the right product to the right customer. They are always searching for ways to get more products out the door in a shorter time to a greater variety of end customers. They often talk in SKUs, which essentially means a separate product.
Two products can have the same circuit board and components, but different firmware for different functionalities. To the end customer, they’re two different products that may be sold next to each other on the same shelf, but for different prices.
Each of those products is a separate SKU and will typically appeal to different parts of the market. By designing with flexibility in mind, a good design should be able to be expanded upon quickly and easily to create different SKUs.
Consider adding stuffing options to your project that will allow add-on cards if needed, with access to the control and data buses directly from your host processor. This will immediately enable you to add an extra pair of channels if needed, or to use a different amplifier in some SKUs but not others, simply by adding a card and changing the firmware. In our Value Soundbar Reference Design, we added headers to take a wireless module and communicate with a wireless subwoofer (Fig. 2).
This simple addition allows end customers to quickly have two differentiated products: a 2.0 stereo soundbar at one price, and a 2.1 wireless subsystem at another price, all developed within one overall development cycle.
This has the immediate advantage of making it much simpler to pass various CE, UL, and Federal Communications Commission certifications, based on your primary design, as well as making inventory control simpler, because you can use the same board and components to build multiple products for multiple different retail outlets and products.
Finally, such additional ports, especially those with I2C or SPI, can be used as a programming port during production and prototyping. Very useful! We’ll cover more on design for manufacturing in upcoming articles.
References
- To learn about the Value Soundbar Reference Design: www.ti.com/soundbarrefdesign-ca.
- To learn more about the PCM3070 stereo audio codec: www.ti.com/pcm3070-ca.