Case study: Cost-effective and rapid audio headset design and verification

Introduction
The consumer market for telephone headsets is noted for its innovative products and its fast pace. Companies bring products to market with new features on an almost weekly basis.

In this environment, the market life of headsets is becoming very short; in fact, some products can be sold for only six months or so. This puts severe downward pressure on our project development times. We have to get to market before the competition, with a headset that offers features the competition doesn't have. At Plantronics, we've developed a novel design platform to help us accelerate innovation, development, and verification.

Development challenges
A consumer telephone headset combines several interacting components, each with its own very different behavior. For example, effective noise cancellation depends on the interaction of the microphone, the earphones, electronic signal processing, and people. We rely on so-called golden ears listeners to assess audio quality, so people are very much part of the headset development process.

To provide better audio quality and more features, we add more signal-processing, which requires more powerful embedded hardware and software. This introduces compile-build-download delays into our development process.

Consider a test scenario in which a golden ears listener detects an audio issue, perhaps with adaptive gain. We correct the adaptive gain algorithm, recompile, and build our software using an IDE on a PC. We download the built software to our embedded hardware and start the testing process all over again. Each bug we detect results in another costly and time-consuming compile-build-download cycle.

In analyzing this process, it is clear that it would be much more efficient to tune the signal-processing algorithms while the call is in progress by altering algorithm parameters, or even completely changing the algorithms used. This would enable us to substantially reduce the time and cost of fixing bugs and improving performance. In the adaptive gain example, if we could alter the gain algorithm while the test was running, we could implement and test our fix much more quickly.

Unfortunately, standard embedded development environments offer limited support for this kind of real-time, on-the-fly modification.

While we couldn't eliminate the build-compile-download cycle, with the right platform we knew we could rapidly create and test algorithms and systems before beginning embedded development. This would enable us to work out the bugs in our system before we started to implement it on an embedded target.

To do this, however, we needed a platform that incorporated human listeners, audio hardware, and signal processing in the same system. We needed a platform that enabled us to make changes to our system as it was operating. Of course, we also wanted it to be flexible and cost-effective.