This is a monthly series featuring embedded developers of the ARM Connected Community.
Paul Beckmann received his BS/MS in EE from MIT and then went on to get his PhD from Prof. Oppenheim’s DSP group. All those who studied DSP mostly likely used the Oppenheim and Schafer book. After graduating from MIT, Paul worked for Bose in R&D and Advanced Product development for 9 years. In 2001, a friend called and invited him out to sunny California to join a GPS start-up which was subsequently acquired by Sirf, Inc. In 2003, Paul returned back to his audio roots and started DSP Concepts offering audio DSP design tools and consulting services.
After giving a talk at the 2009 Audio Engineering Society Conference, Shyam Sadasivan, a product manager at ARM approached me. ARM then engaged DSP Concepts to write the CMSIS DSP library for the Cortex-M4. That opened the door for us to expand our Audio Weaver® audio design tool from supporting traditional DSPs to include the ARM architecture. We now support most ARM Processors including the Cortex-M4 and Cortex-A family.
That’s like asking which one of your children is your favorite. We do about 10 to 15 products per year. I will tell you about a couple of our interesting products. We are probably the leading provider in automotive e-sound. In Europe, there is legislature that requires electric vehicles to make pedestrian alert sounds because the electric vehicles are silent at low speed and often sneak up on pedestrians. The e-sound system includes an external speaker that generates audio in response to vehicle data like speed and acceleration. At high speeds, the system gradually shuts off since the car can produce enough noise of its own through tires rolling on the road. Currently we provide the tools and our customers use them to develop their own signature sounds. One sounds like a spaceship, another like a V8 engine. Can you imagine the day when one can download their own personal e-sound much like a ring tone? These were done on an ARM926 and another version will be on the Cortex-A15.
Along the same veins, the irony of today’s more efficient combustion engine is that it can make more horse power with fewer cylinders. As a result, the engines sounds are not creating the big muscle car sound some are used to. One of the projects is to make additional engine sound on the inside, so one can “feel” the power of the engine. The simulated sound has to pass mustard with the exhaust engine sound experts at the car OEMs.
Traditionally, audio digital signal processing has been done on DSP (digital signal processors). With these specialized processors, an engineer needs to write in assembly in order to get the full performance out of the devices. Audio is especially hard because any lag or delay or dropouts from stalls or slow processing would not be acceptable. Today there is a trend to adding connectivity to most consumer products. DSPs have poor support for connectivity but microcontrollers, on the other hand, excel at connectivity. DSPs lack the ecosystem that ARM has cultivated for software support for drivers and operating systems. So one would ask, is it easier to add connectivity to a DSP or DSP functions to a microcontroller? It turns out it’s easier to add DSP extensions to a microcontroller – microcontrollers are now fast enough for many audio applications.
Many companies have no audio capabilities and rely on ODMs to do their design. The problem with this is that they all sound the same, no differentiating advantage. It is very hard to find a good audio DSP engineer. They are specialized in that they need to know the underlying mathematics, be able to program efficiently, and have an understanding of psychoacoustics. On the other hand, there are good audio engineers with trained ears but they can’t write DSP codes. This delay in having to throw a design over the fence then wait for the code to be implemented before they can hear slows down the whole audio design process.
Some overseas product makers think of cheap cost parts only. The problem is they go through a check list of features without being able to really evaluate the quality. It’s like buying a piano and assuming as long as there are 88 keys, a $1,500 piano sounds the same as a $150,000 piano. Many of the extremely low cost parts are fixed function devices. A good audio product requires attention to the overall system design. It’s the combination of mechanical, electrical, acoustical and software implementation that sounds good. No fixed function device can deliver the quality of a well-tuned and programmed audio design on a programmable device. For example, Jawbone invests lots of engineering resources into audio quality. It is very difficult to get good sound out of a small enclosure. The Jambox portable speakers are remarkable sounding. Though one might find myriads of other Bluetooth speakers walking through CES show, the cheaper knockoffs are not worth the money for the sound except for the plastics they come in.
Yes, our very high quality sample rate converter is asynchronous, meaning that it can convert from any sample rate to any sample rate – even if they are slowly varying, is ready and available for the ARM Cortex-A and Cortex-M4. There are two clocks that need to work together, one from the transmitter, and another at the receiver. Imagine you have two watches, over the course of one day, they might drift apart by 1 second. That may not seem like much, but at audio rates, that’s over 40,000 samples. This wasn’t a problem with analog transmission, but with more and more digital streaming, this is becoming an issue. Our ASRC can reach a THD (Total Harmonic Distortion) of -140 dB which is accurate to 1 part out of 10 million. This creates clear non-distorted sounds even at high frequencies which is hard to do. On the Cortex-M, it is optimized using the DSP extensions. On the Cortex-A, it is optimized for the NEON. Both cases use 32-bit accuracy. On the Cortex-A a stereo stream at 48 KHz requires 30 MIPs, and 42 MIPs on the Cortex-M.
There are intricacies that one needs to take into account when doing a sample rate converter for audio application. One can’t simply apply linear interpolation. In order to achieve clarity and imaging, especially in the high frequency spectrum, one needs to be careful to properly apply antialiasing filters. This is usually beyond the expertise of a regular software engineer, and even a DSP engineers without the proper audio background has difficulty making the right tradeoffs.
ARM’s DS-5 compiler. My engineers all love the debugging feature called Undo-DB. It allows the programmer to step backwards while debugging, which is pretty nifty.
A good way to start coding DSP applications on ARM is to start with the CMSIS DSP library. And if the function you need is not there, then write it in C with Intrinsics and not assembly. You will get 90% of the speed while keeping the ease of a C programming model.
My vision is to enable all audio product developers to easily and quickly develop innovative products. Our Audio Weaver design tool with the graphical user interface and real-time tuning capabilities is beginning to be adopted by many automotive partners as their unified audio framework. The tool is developed from years of embedded audio product development expertise. It contains over 400 basic audio blocks than can be combined to create most designs. There’s also customized API capabilities as well.
For audio engineers, if they can run a sound board, they can build a quality audio product. For DSP engineers, rather than dealing with assembly codes, they can focus on designing sophisticated filters and audio algorithms. For product marketers, they can shorten their time to revenue and create innovative applications and estimate DMIPs and cut BOM costs. And for consumers, we all benefit from better product offerings.
We have a very similar model to ARM. We have encapsulated the DSP building blocks with hand optimized code for different target processors, so that product designers can focus on their core competency of designing a great sounding product rather than spending their energy on the grunt work. We want to be the glue that helps integrate the various components necessary in an audio product: algorithm development, system signal flows, and optimized target processors codes.
I love wood! My proudest achievement is winning the Golden Hammer Award in my senior year in high school.
Previously Featured Embedded Developers
Embedded Developer Feature: James Langbridge, Author of Professional Embedded ARM Development
Embedded Developer Feature: Colin Walls, Embedded Software Technologist at Mentor Graphics
Embedded Developer Feature: Jacob Beningo, Certified Software Development Professional
Brad Nemire