[Indigo]<Voice>Stewart>audioresponse.bravo!1

Butler Lampson, in [Ivy]<CSL-Notebook>81CSLN-0030.press, has given concrete form to the long standing proposal for an auxiliary I/O board for the lab’s D-Machines. Butler’s plan includes DES encryption hardware, a source of random numbers, a time receiver, some amount of stable storage, but not audio. The chief reasons for not including audio are that D-machines are becoming more distant from our offices and that an ethernet audio peripheral is becoming feasible.

As stands, the proposal referred to above is not adequate for our needs over the next few years. The auxiliary board should provide for audio and it should provide for new I/O devices such as scanners, printers, tablets, and laboratory instruments. In particular, the board should include:

With the possible exception of the WWV time receiver, Butler’s proposal does not include any I/O devices. The time receiver is a specialized I/O device because it does not need any connection to the user’s office. Because they are large and hot, we have banished Dorados from our offices. Because they do not have any often used controls, we have gotten away with it. (To a lesser extent, the same things are true of Dolphins.) However, we must not freeze the functionality of our computers just because they are farther away. We are already planning to install black and white display cables from the machines to their owner’s offices; we can pull other cables at the same time: color display, audio, junk I/O. The extra wire is not free, but it is not so overwhelming that we should overlook its benefits!

Ethernet peripherals will not be here next week. While we can and should start work on a small machine, perhaps one of the 16 bit microcomputers, to connect various devices to the Ethernet, such a machine cannot be generally available for 18 to 24 months. Any reasonable design for such a gadget depends on the availability of a single chip Ethernet controller -- which will not be available for about that period.

An additional benefit arises from using D-machines for I/O devices instead of stand-alone machines: we can use the leverage of Cedar. We will probably not be able to write software for an Ethernet peripheral at a higher level than BCPL until we can use a Dragon.

The auxiliary board should include a several channel T1 interface. T1 is the phone company name for a time division multiplex serial signal format which supplies 24 channels with 8000 8 bit samples per second, for an overall data rate of 1.544 MB/second. Each channel runs at 64,000 bits per second. Single chip devices called CODECs (for COder DECoder) exist which use a single T1 time slot and convert to and from audio. The auxiliary board could simply send and receive the T1 signal to and from the users office over two cable pairs. At the office, a small box could contain a codec for conversion to and from analog. Alternatively, one or more codecs could be packaged on the auxiliary board, with analog cable to the user. As a side benefit, other devices (non-audio) which can live with a multiple of 64 KB can use time slots on the T1 line to get from the office to the processor. Slow devices can use two time slots, one with a ready bit and the next holding the data. This proposal, in effect, recommends T1 as a general slow/medium I/O bus for our machines.

Without presuming too much of the audio project, there seem to be two somewhat separable audio activities: general telephony and the integration of audio with our other activites. It seems fairly clear that general telephony cannot be seriously pursued without the stand-alone Ethernet peripheral. Our workstations are not designed to be 100% available, nor are they designed for background real-time activites. The integration of audio with our other activities is slightly different. When we have stand-alone Ethernet audio devices, then of course we can use them for annotating documents, sending voice Laurel messages, etc., but we can also do these things with audio interfaces on our workstations. D-machines can certainly handle the real-time requirements of audio when they are running an appropriate program. While I expect the audio project will pursue the stand-alone route for (initially) small numbers of audio devices, the use of workstation based, limited function audio hardware will bring music to most of our ears much sooner. Naturally, the two kinds of audio will play together!

Much of the tremendous value of the Alto has been its ease of interfacing. Many devices have been plugged, at one time or another, into the ubiquitous Diablo port. Unfortunately, never more than one such device at a time! Our D-machines need a simple, easy to use I/O bus for medium bandwidth devices such as printers, scanners, tablets, higher quality audio, footpedals, electric pianos, or what have you. It is true that a simple parallel interface is not reasonable for a machine located too far from its user, but Dolphins, at least, will not be too far away. The use of a single T1 interface for both audio and general I/O has the attraction that the T1 signal can be sent relatively long distances over a single cable pair, but the disadvantage that the end device T1 interface is more complex than a parallel port. Because a simple parallel port with a task wakeup line is so simple, it should probably be included for those many occasions when we want to hook something up very quickly.

The Pup checksum and various cyclic codes are heavily used in our environment. To some extent, the use of chained encryption can substitute, however, hardware assistance for checksum and CRC are very simple. In the case of the Pup checksum, a microcode implementation might be fast enough.