Soundbar design encompasses many divergent yet essential steps (see http://electronicdesign.com/author/dafydd-roche). For example, the marketing team’s specification must be decoded into component selections. Various converter and amplifier topologies must be examined. And, there’s in-circuit and production line programming.
In terms of hardware, the soundbar reference design we have been developing uses an MSP430 16-bit low-power microcontroller to handle the control, user interface, and housekeeping duties. The PCM3070’s dual miniDSPs manage the audio processing (Fig. 1).
This file type includes high resolution graphics and schematics when applicable.
The code for the miniDSPs is kept externally on an additional EEPROM, as we had some concerns regarding the number of different process flows required for the miniDSP. By process flow, I refer to a different audio processing flow for, say, Sony/Philips Digital Interchange Format (S/PDIF) content versus analog input, or different audio processing for 44.1-kHz content versus 48 kHz. Each process flow requires its own code and coefficients, increasing the amount of flash space required on the microcontroller, if we decide to keep everything in the microcontroller.
In practice (and hindsight), we found that customers typically had two process flows (44.1 and 48 kHz). In fact, most had one process flow, with different coefficients for 44.1 kHz and 48 kHz.
Related Articles
- Soundbar Design From Start To Finish: From Specification To Selection
- Soundbar Design From Start To Finish: Setting Design Specifications
- Soundbar Design From Start To FInish: Choosing And Controlling An Audio Processing Scheme
In the rest of this article, we’ll discuss the software that was developed to boot the code for the miniDSP codec from an external source, mainly because that's what was done, but also because it provides a good example of such software management, should you have multiple process flows in your product.
The software in an audio system, such as a soundbar or PC speaker, can be split into a few different sections: control and user interface (decoding IR, receiving button presses and de-bouncing them), housekeeping (boot up and maintenance of multiple devices), and audio signal chain processing (audio processing that sits between the input and speaker amplifiers).
Control And User Interface
A separate daughter card with physical button interfaces was created to fit in with the typical industrial design of soundbars. The physical user interface is simply a bunch of switches connected to general-purpose I/O (GPIO) pins on the microcontroller, along with a bunch of electrostatic discharge (ESD) diodes.
Software-wise, it’s painfully simple. An interrupt detects one of the buttons pushed (with a signal pulled to ground), a small timer is run (for debounce), and the I/O port is checked again to see which button was pulled to ground. Based on which button is pulled to ground, a function is run (such as “switch to USB input”).
The IR remote control is a tougher challenge.1 There are two different consumer IR protocols, NEC and RC-5. Both work using a similar physical layer. The protocol really has more to do with timing and word depths. Credit where it’s due, the NEC format (or Japanese format) is mainly attributed to the team at NEC, while RC-5 was developed by Phillips.
IR transmitters and receivers typically have to be matched in frequency. For example, the ones used in the soundbar reference design run at 38 kHz. Data is amplitude modulated into the transmitter and filtered out by the receiver. At the receive end, the system will not see the carrier frequency, only content that looks like UART serial stream data. For instance, with RC-5, we end up with content coming out of the receiver at 1.778 ms per bit (64/38 kHz).
From a code perspective on the microcontroller, an IR decoding function is started when the serial stream’s starting bits trigger the microcontroller’s GPIO pin. Once a valid, relevant code has been received, the appropriate button-press function is run, essentially making the IR command emulate a physical button press.
This file type includes high resolution graphics and schematics when applicable.
Housekeeping
The same MSP430 is used for all housekeeping duties, such as booting up the PCM3070, ensuring the TPA31xx amplifier is muted, and keeping an eye on the lock status of the digital audio receiver (DIR9001). The PCM3070 has pages of registers that look after the hardware side of things such as clock configuration and input channel multiplexer selection. Then, another specific set of pages looks after the instruction and coefficient data.
The microcontroller’s code base maintains the hardware registers for the miniDSP codec, since they tend to be fixed for all inputs and usage cases across Texas Instruments’ customer base (analog versus digital input). Once initially booted, only a few register changes are needed. For example, changing from analog input 1 to analog input 2 is a matter of a few register writes.
The miniDSP code for the miniDSP codec is much bigger and likely to change from customer to customer. In that case, we put each process flow and related coefficients into an external EEPROM, which can be loaded by the microcontroller, in a “copy and paste” fashion.
For instance, on startup, the microcontroller reads the register from the EEPROM and writes it directly to the miniDSP codec. It’s a little simple, but it works well, and we didn’t see audible latency in startup. Other interrupts in the system such as S/PDIF lock signals were brought into the microcontroller to alert us when we’ve lost lock and to change to the analog input by default if needed.
On input changes such as analog 1 to analog 2, the shutdown pin of the amplifier is initially set to mute. Then the various register changes are made in the miniDSP codec, followed by an unmute of the amplifier. This provides a pop-free experience. That’s what good housekeeping is all about!
This file type includes high resolution graphics and schematics when applicable.
Audio Signal Chain Processing
The audio signal chain (or process flow used on the PCM3070) can be the same regardless of audio source (analog or digital) since the miniDSP on board the device simply sees the data as pulse coded modulation (PCM)digital data at a specific clock rate.
The default audio signal chain initially was tuned using the PCM3070 evaluation module (EVM) and PurePath Studio home software (PPS). Once the prototype of your process flow is sounding good, the next step is to document the interface and export the configuration file for use in the EEPROM on the board.
Documenting the interface ensures that you know the register addresses for the coefficients you want to modify in the system. For instance, if you want the ability to bypass an effect (such as SRS WOW HD), then you need to know the register address for the software multiplexer in the process flow (Fig. 2).
That register address will be used in your MSP430 software, specifically in your button-action code. Other examples may be in equalization (EQ) settings, allowing users to change between pop, jazz, and classical mode EQs.2 Multiple images (or configuration files(CFGs)) can be stored on the EEPROM and can be loaded from the microcontroller with a simple call.
Getting Into Production
You now have an MSP430 hex file, along with an external EEPROM hex file. How on Earth are you going to get the code into their respective places? In the soundbar reference design kit, we opted to have a separate board with pogo pins that the soundbar board could be placed upon in the factory (or screwed onto in the development environment).
This programming board has headers for the standard MSP430 14-pin programming spi-bi-wire, as well as a TAS1020B USB streaming device used to send I2C commands. Using this tool, the microcontroller and the external EEPROM can be programmed separately, with separate tools.
The caveat to all this is that the MSP430 wants to be the I2C master, once it has been flashed/programmed. However, the TAS1020B also wants to be the I2C master. As such, the sequence of programming is very important! The EEPROM must be programmed first via the TAS1020. Next, temporarily disconnect the TAS1020, then program the microcontroller.
In hindsight, putting all code in the microcontroller’s onboard flash would have saved a lot of the heartburn associated with two I2C masters fighting on the same bus. Additionally, I would have specified a simple UART interface on the microcontroller to be connected to a simple USB serial port cable that could be used for debug.
The soundbar reference design kit has been quite successful in different form factors as soundbars, MP3 docks, and PC speakers. The combination of easy-to-use tools for the MSP430, PurePath Studio, and SRS WOW HD royalty-free makes the package rather compelling!
References
1. I found a great resource for IR knowledge that you might find interesting: http://www.sbprojects.com/knowledge/ir/nec.php.
2. For more detail on developing software for the reference design kit, read this software guide: Value Soundbar Reference Design Kit Development Guide.
3. To find out more about the platform head, check out this Value Sound Bar Reference Design Kit.
4. Download these datasheets: www.ti.com/pcm3070-ca, www.ti.com/tas1020-caand www.ti.com/tpa3116d2-ca.
5. For audio support, visit the TI E2E Community forum for audio amplifiers: www.ti.com/audioampe2e-ca.
Dafydd Roche is one of TI’s Audio Systems Engineers. When he’s not busy trying to define smarter, easy-to-use products so customers can stand out from the crowd, he’s busy shaking his cubicle walls doing listening tests with TI’s DACs and amplifiers. Dafydd enjoys Tex-Mex food (a change from his native Wales), talking with customers about their development issues, and putting the world in order on TI’s e2e audio forum (e2e.ti.com). He can be reached at [email protected].
This file type includes high resolution graphics and schematics when applicable.