From algorithm to market: Real‐world issues in speech development projects

Abstract

Papers on speech technology have typically addressed issues in one of two disparate areas: (a) hypotheses and observations aboul articulatory, auditory, or acoustic aspects of speech production and perception, and the development of the algorithms that underlie those observations; and (b) marketing and sales issues somewhat or totally unrelated to (a) such as competitive analyses, industry‐specific applications, and applications software or the user interface. There is, however, a complex world of logistics that afffects a speech technology project in the most fundamental way. Nothing describes this more accurately and effectively than a brief history of the DECtalk development project at Digital Equipment Corp. It is a realistic illustration of the evolution from laboratory system to product. In 1981, Dennis Klatt, a senior research scientist at MIT, was searching for an industrial partner to help develop and produce a text‐to‐speech system derived from Klatttalk, a set of algorithms for a speech synthesizer that he had been working on since 1970. After almosl 9 months of searching, he found individuals within Digital Equipment Corp. who were willing to risk the costs of an extensive development project for a technology which, at the time, had no market. This relationship between academia and industry turned out to be so mutually beneficial and enlightening that Klatt was prompted to discuss it publicly from the academician's perspective [D. H. Klatt, Proc. Speech Tech. '87, 293–294 (1987)]. This discussion outlines some of the more important logistical issues from the corporate point of view and a description of these constitutes a typical project history: problems in hardware design and development; dependence upon external engineering and support groups (e.g., manufacturing, technical documentation, etc.) and external vendors; and testing for design verification/maturity and physical robustness. In addition, speech development was proceeding simultaneously in two separate places (Maynard and MII), the need to run in real‐time entailed the perennial decisions on cost versus performance, and debugging cycles required constant compromise.