In the early days of DSPs (circa the mid ‘80s), audio compression and other audio algorithms really taxed the performance of the processors available at the time. And high-level language compilers for DSPs were, for the most part, lame. Therefore, real-time implementations of audio algorithms almost always required hand-optimized software. Now, 20 years later, processor performance has improved dramatically, and compilers are much better. So you might think the days of hand-tuning audio software are behind us.
They’re not.
There are several reasons for this. First, audio algorithms have increased their performance requirements—not at the same rate as the increase in available processing horsepower, but still, audio algorithms are significantly more demanding than they used to be. Second, today’s audio algorithms typically share the processor with lots of other tasks: video algorithms, media players, network stacks, GUIs, OSs, etc. The less processing power the audio algorithms use, the more available for other tasks. And third, products that are cost-sensitive or energy-conscious need tightly optimized code that doesn’t waste any cycles (or milliwatts).
While compilers are much better than they once were, it’s still the case that getting an audio algorithm running in the minimum MIPS requires careful hand optimization by engineers who understand both the algorithm and the target platform.
Recently, an audio algorithm company needed to optimize its proprietary algorithm for a new platform in order to win a key customer design. The company ported the algorithm to the target platform and did some initial optimization work, but with four weeks left to delivery, the performance still wasn’t good enough.
Recognizing that it didn’t have the internal resources to get the job done in such a short timeframe, the company engaged BDTI for quick, expert help. With BDTI’s encyclopedic knowledge of processor architectures, extensive background in digital signal processing, and detailed knowledge of software optimization techniques, the BDTI team was able to quickly jump in and find opportunities for further optimization.
One very fruitful optimization was to identify redundant operations that could be combined or eliminated. For example, one loop that included signal scaling was immediately followed by a call to a function that scaled the signal (again) according to an externally supplied parameter. Algorithm analysis demonstrated that the two separate scaling steps could be safely merged, completely eliminating the overhead of a second pass through the entire audio frame (with the associated memory loads and stores). Similarly, BDTI was able to replace a number of expensive multiply-and-saturate operations with simpler multiply operations by analyzing the algorithm and proving that the data could never overflow at the points in question.
By carefully analyzing the algorithm and optimizing the code, BDTI was able to shave cycles in a dozen different places and get the code running well under the MIPS budget—within three weeks.
To learn more about BDTI’s software optimization capabilities, contact Jeremy Giddings at BDTI (giddings@bdti.com) or visit www.BDTI.com.
Add new comment