|
|
DACS: Overall System: The Distributed Concept | 
|
Next: Functional Design Up: High-Level Software Design Previous: High-Level Software Design Contents Overall System: The Distributed ConceptThus far, very little of this design document has stressed the concept of distributed audio control. This is because much of what makes DACS distributed is implemented in the high-level system software. DACS takes advantage of off-the-shelf PCs and peripheral hardware. These days, powerful PCs with network cards, CD-ROMs, and sound cards are commonplace. DACS can use any number of networked PCs to scale to almost any conceivable audio application. For example, a network of six PCs could be used in an audio application requiring a dozen audio CDs, six digital audio sound cards, four separate MIDI buses, two DACS mixer units, and a control board. While this is something of an extreme case, it merely serves to illustrate the possibilities. To make DACS services truly distributed, a client/server approach is used. TCP/IP, a widely available network protocol, provides a reliable way to communicate over a wide variety of computer networks. The base model for DACS is communication over standard 10Mbit ethernet. This does not preclude the use of 100Mbit ethernet, ATM, or other physical media. TCP/IP even works on a single, non-networked host. This makes implementation easy, and allows the distributed paradigm to be scaled down to a single PC application. Figure 107 shows a system view of the DACS software, with emphasis on the distribution of services. Note that where TCP/IP is seen as a communications means, the software components may be run on separate machines. The central application, dubbed q2q, acts as a master to all of the various DACS components, wherever they are located in the DACS configuration. This GUI-based program allows complex audio scripts to be built using an intuitive interface. Editing and creation of these scripts may also take place by using the control board standalone, or as a supplement to the GUI. Audio scripts can be of two overall types, time-cued or user-cued. Time-cued scripts tend to be used in situations where SMPTE synchronization is desirable, such as in broadcast audio or studio recording. User-cued scripts tend to be used in situations where manually starting each cue is necessary, such as in a theatre setting. Manual cueing does not preclude the possibility of having time-subcued audio events. Various DACS service providers allow the q2q software to access DACS subsystems. Currently, service providers for the mixer unit, control board, generic MIDI interfaces, generic PC soundcards, and generic PC CDROM drives are envisioned. Abstracting the underlying hardware from the higher-level software provides the distinct advantage of compatibility and simplicity from the top down. As new hardware with a similar functionality set comes along (such as a PC-based MiniDisc drive, for example), upper-level software does not need to change much to accomodate this new device. A generic class of transport-style devices can be created, all of which are accessed similarly from the q2q software. Distributing the services among several programs also reduces the problem with q2q becoming an excessively monolithic program. This reduces memory consumption, size of the program, and allows a much more scalable system to be built.
Next: Functional Design Up: High-Level Software Design Previous: High-Level Software Design Contents Steve Richardson 2000-07-06 |
Table of Contents
| |
![[PDF]](/~prefect/images/pdficonsmall.gif)
[Whole document in PDF 1.9MB]