This vastly complicated software engineering. APIs were thin and programmers were forced to compose much of their own middleware for interrupt service, sometimes dropping into assembly language to insure that service was sufficiently rapid to avoid interrupt pileups and re-entrancy problems with the operating system.
As multiprocess/multithreaded OSs (e.g., Windows NT) came online, these asynchronous architectures had to be adapted to the imperious realtime demands of the hardware - another big project. Direct access to signal-processing features too, while arguably necessary, added yet another level of complexity, both for application creators and integrator/tweakers.
The industry attacked these problems simultaneously, on several fronts. The advent of telephony buses - PEB, MVIP, SCSA - implemented as a continuous series of ribbon-cable connections across the top of xISA cards, plus switching logic and firmware on the cards themselves - provided the first glimmerings of a solution to single-chassis performance issues; as well as the means (at least in principle) for extending the functionality of an application to multiple chassis, increasing line-counts and enabling new ways to package and scale telephony systems.
Telephony buses, clocked independent of the system bus and providing several thousand PCM timeslots of capacity, provided a separate set of pathways for switching isochronous data streams (usually PCM) among multiple devices - avoiding contention with basic system housekeeping and significantly increasing overall throughput.
The appearance of telephony buses worked a basic philosophical change in the economics and engineering of computer telephony systems. Availability of a systemwide "real-time resource switching and pipelining" facility encouraged engineers to begin thinking of computer telephony systems as "abstract pools of resources" that could be connected and released as needed, rather than discrete islands of functionality.
