WO1991018345A1

WO1991018345A1 - Voice message decoding and buffering system

Info

Publication number: WO1991018345A1
Application number: PCT/US1991/003407
Authority: WO
Inventors: Allen L. Adkins; Dana Redington; David Boulton; Hien Tran
Original assignee: Optical Media International
Priority date: 1990-05-22
Filing date: 1991-05-21
Publication date: 1991-11-28

Abstract

An audio message decoding and buffering system (110) includes a microprocessor (120), a set of message buffers (134) for storing voice messages, and a bus (104) which couples the system to a host computer and a CDROM. The system is pregrogrammed to accept a set of commands from the host computer (102). In particular, the host can instruct the system to preload specified messages in specified ones of its message buffers, and then the host can instruct the system to play back any one or specified set of the voice messages storred in its buffers. In addition, the host can send voice data for storage in a specified message buffer. The system is also programmed to use interleaved CDROM data. In this mode of operation the system simultaneously plays audio data retrieved from the CDROM while transferring to the host computer other data which is interleaved with the audio data being played. Finally, the host can access the CDROM directly, for example so that it can retrieve non-voice data directly from the CDROM.

Description

VOICE MESSAGE DECODING AND BUFFERING SYSTEM

The present invention relates generally to a system for retrieving data from relatively slow memory media such as CDROMs and particularly to methods and systems for real time voice data retrieval from such media for use in an interactive system.

BACKGROUND OF THE INVENTION

CDROMs, optical disks used to store data, are a convenient storage media when it is necessary to store a large amount of data at low cost. A significant problem associated with the use of CDROMs in commercial applications is that it can take up to one second to access a specified block of data on a CDROM. This delay is herein called the "maximum CDROM access time" or the "maximum CDROM indexing time". Once the CDROM drive has moved its read head to the specified block, the rate of data retrieval is quite acceptable for most commercial applications. However, in systems which require a quick response to a data request, such as a real time voice response system, a delay of one second is unacceptable.

To improve the usefulness of CDROMs in interactive systems, a data storage format lαiown as CDI (which stands for "compact disk interactive") has been developed. Within the set of formats that fall under the CDI label, there are a number of specific formats, including one called the "XA" (extended architecture) ^"CDI format, which allows for interleaving compressed voice data with other types of data. While the CDI formats are useful, and help to improve the usefulness of CDROMs in interactive systems, these data formatting methods do not overcome the problem that the maximum CDROM indexing time is equal to about one second.

The present invention overcomes the long delay time associated with CDROM indexing in systems in which the next data retrieval can be anticipated. In particular, the present invention is an intelligent message buffering system in which a number of voice messages can be stored in specified message buffers. A host system determines all voice messages which might possibly be needed in the immediate future (typically, there are between two and ten such possible messages) , and instructs the message buffering system to store all these messages in its message buffers so that they will be available for immediate playback by the host.

SUMMARY OF THE INVENTION

In summary, the present invention is an intelligent voice message decoding and buffering system. The message buffering system includes a microprocessor, a set of message buffers for storing voice messages, and a bus which couples the message buffering system to a host computer and a CDROM. The message buffering system is preprogrammed to accept a set of commands from the host computer. In particular, the host can instruct the message buffering system to preload specified messages in specified ones of its message buffers, and then the host can instruct the message buffering system to play back any one or specified set of the voice messages stored in its buffers. In addition, the host can send compressed voice data to the message buffering system for storage in a specified message - 4 -

Figure 4 depicts the set of software routines in the message buffering system of Figure 1 which are available for use by a host computer.

Figure 5 is a block diagram of a second preferred embodiment of the present invention, using two communications busses.

Figure 6 is a block diagram of a third preferred embodiment of the present invention in which the message buffer subsystem also performs the functions of a host computer.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to Figure 1, there is shown a computer system 100 which includes a host computer 102 which coupled by a SCSI bus 104 to a CDROM drive 106 and a message decoding and buffering system 110, also herein called the message buffering subsystem. The CDROM drive 106 holds a CDROM 108 in which is stored both compressed audio data and other data. The present invention is primarily concerned with the compressed audio data stored on the CDROM 108.

In the preferred embodiment, the bus 104 which interconnects the host 102, CDROM drive 106 and message buffering subsystem 110 is a standard SCSI bus. Protocols associated with the use of SCSI busses are well known and are therefore not described herein. Other standard bus architectures could be used in place of the SCSI bus.

AUTOMOBILE NAVIGATION SYSTEM.

The preferred embodiment of the present invention is tailored for use in automobile navigation (i.e., route selection and guidance) system. The system 100 instructs the driver of a car on what route to take to a specified destination and orally advises the driver as to the - 3 - buffer. The voice data ^'stored in various ones of the message buffers can be concatenated to form new messages.

The message buffering system is also programmed to make use of the interleaved data format used with some CDROMs. In this mode of operation the message buffering system simultaneously plays audio data retrieved from the CDROM while transferring to the host computer other data which is interleaved with the audio data being played.

Furthermore, the host can access the CDROM directly, for example so that it can retrieve non-voice data directly from the CDROM.

In an alternate embodiment, the message buffering system can be programmed to perform the functions of both a host computer and a message buffering system.

BRIEF DESCRIPTION OF THE DRAWINGS

Additional objects and features of the invention will be more readily apparent from the following detailed description and appended claims when taken in conjunction with the drawings, in which:

Figure 1 is a block diagram of a system incorporating a preferred embodiment of the message buffering system of the present invention.

Figures 2A and 2B are block diagrams of data blocks retrieved from a CDROM.

Figure 3 is a block diagram of the message buffers and related data structures used for storing and playing back audio data. driver's progress. For example, the system can advise when a turn should be made or a mistake has been made. The host 102 includes a touch screen (not shown) . When the screen is touched, it orally advises the driver as to the status of the car along the selected route. For example, when prompted by a screen touch, the host 102 will inform the driver how far it is to the next turn. The host 102 anticipates all the possible instructions that the driver may need as the car approaches an intersection, and stores the corresponding audio files in the message buffers of the message subsystem 110. When the host 102 decides to enunciate a message, the corresponding audio file is already loaded in a message buffer. Therefore all the host 102 needs to do is instruct the message buffering subsystem 110 to play the message that is stored in a specified message buffer.

Note that details of the host's hardware and operation are not part of the present invention and are not described herein. The brief description of the host 102 herein describes the general context in which the preferred embodiment of the message buffering subsystem 110 operates.

In the preferred embodiment, the CDROM 108 stores both audio data for generating messages, and also routing data used for displaying maps on a video display (not shown) and for selecting a route to be used by the driver. The present invention provides two mechanisms for sending data from the CDROM 108 to the host computer 102. The first such mechanism uses data interleaving c_* the CDROM. Audio and other data are interleaved within each interleaved

CDROM file. While playing the audio data, or a specified channel of the audio data in a specified CDROM file, another specified portion of the data in the CDROM file is transmitted to the host computer. For instance, interleaved data could be used to enunciate the message

"please wait while additional routing information is retrieved," while the host computer 102 retrieves new or additional route selection data from the CDROM 108. In some instances, the data sent to the host 102 may be video data for display on the host's monitor (not shown) .

The second mechanism for sending data from the CDROM to the host computer 102 is that the message buffering subsystem 110 can "release" the CDROM drive 106 for direct access by the host computer 102.

MESSAGE BUFFER AND DECODER.

As shown in Figure 1, the message buffering subsystem 110 includes a microprocessor (CPU) 120 which is coupled to the SCSI bus by a bus interface circuit 122 (via internal system bus 130) of standard design. The CPU used in the preferred embodiment is an 80188 microcontroller manufactured by Intel. The software for the CPU 120 is stored in a read only memory (ROM) 124 which is coupled to the CPU 120 by a local system bus 130. Also coupled to the CPU 120 by the local bus 130 are a random access memory (RAM) 132 for general use, and a set of message buffers 134. In most implementations the message buffers 134 are stored in the same physical RAM as the general use memory 132, with the message buffers occupying a predefined portion of the address space assigned to RAM. In the first preferred embodiment, the total amount of RAM is 512 kilobytes, with 384 kilobytes being used for the message buffers 134 and 128 kilobytes being used for storing software, tables, miscellaneous data and for temporary storage of non-audio data being retransmitted to the host computer 102.

In the preferred embodiment, whenever the subsystem 110 is powered on or reset the software stored in ROM 124 is loaded into RAM 132 because this improves the execution speed of the software. Approximately 64 kilobytes of software are copied from the ROM 124 to the RAM 132 during this process.

A digital signal processor (DSP) , which in the preferred embodiment is an ADPCM decoder 140, converts ADPCM encoded audio data into an analog audio signal. In the preferred embodiment, the ADPCM decoder is circuit number YM-6064 manufactured by Yamaha/Microboards. Packets of ADPCM data are transferred from the Message Buffers 134 to the ADPCM decoder 140 via the local bus 130 in response to PLAY commands sent by the host computer 102. More specifically, compressed audio data from a specified message buffer is first transferred to an 8 kilobyte static RAM 136 coupled to the ADPCM decoder 140, and then the decoder 140 plays (i.e., decodes) that data. The resulting audio signal is bandpass filtered (with a band pass of 2K to 2OK) by filter 142, then amplified by a pre-amplifier 144. The filtered and amplified audio signal output by the pre-amplifier 144 is transmitted to an external device 148, such as an audio speaker or tape recorder, by audio connector 146.

Before playing a message, the CPU 120 instructs the decoder 140 that a particular number of audio packets are to be decoded. The decoder 140 then generates interrupts signals which prompt the CPU 120 to transfer data packets into the decoder's dedicated static RAM 136 until that RAM 136 is either full, or the end of the message is reached. Furthermore, as the decoder 140 plays the data packets stored in the RAM 136, if the number of packets which have been transferred to that RAM are less than the number of packets in the message, it generates further interrupt signals which cause the CPU 120 to transfer subsequent portions of the message to the RAM 136.

It may be noted that when the ADPCM decoder 140 is generating audio signals using compressed "C-MONO" audio data, it must be loaded with 84.375 audio data packets per second, each audio packet having 128 bytes of ADPCM encoded data. This represents a sixteen to one compression of the audio data. To do this, the ADPCM decoder 140 simply reads in another packet from its local static RAM 136 every time that it is ready to receive another packet of data. As described above, the decoder 140 also generates interrupt signals that are sent to the CPU so as to keep the static RAM 136 loaded with compressed audio data before that data is needed. The CPU 120 has an interrupt routine which responds to each ADPCM interrupt signal by sending a packet of audio data from one of the message buffers 134 to the static RAM 136, via bus 130 and the ADPCM decoder 140, until the end of a specified message has been reached.

Stored audio data in the preferred embodiment is encoded in ADPCM form to reduce the amount of data storage required for storing audio messages. There are six different standard levels of ADPCM audio data compression which are used for storing audio data on CDROMs:

TABLE 1 ADPCM AUDIO DATA COMPRESSION STANDARDS ADPCM LEVEL COMPRESSION RATIO A-STEREO 2:1

A-MONO 4:1

B-STEREO 4:1

B-MONO 8:1

C-STEREO 8:1 C-MONO 16:1

ADPCM encoding is a well known technique and the ADPCM encoding levels shown in Table 1 are the industry standard methods of compressing and encoding audio data which is stored on CDROMs. ADPCM encoders and decoders are commercially available and widely used for efficiently storing speech messages. In the preferred embodiment, ADPCM level C-MONO is used for storing compressed audio data. In other embodiments of the invention, other data compression formats may be used, some of which achieve even greater data compression than ADPCM C-MONO. Greater compression might be useful, for example, if more data needs to be stored on a media, such as a CDROM, which has limited room for storing such data.

Referring to Figure 2A, there is shown the format of one CDROM data block 160 as it is received by the message buffering subsystem 110 whenever it retrieves a block of compressed audio data. This format is known in the CDROM industry as the Mode Two, Form Two block format. The CDROM data block 160 is preceded by twelve synchronization bytes 161. The CDROM block 160 itself begins with a four byte header 162, including a three-byte address and one mode byte, and an eight-byte subheader 164 which specifies the file number, channel number and block type of this particular block, and an audio level if the block contains audio data. Next, there are 2304 bytes of compressed audio data 166, followed by a twenty-byte gap (i.e., zeros) 167 and a four byte error detection code 168. The 2304 bytes of data 166 include 18 packets of data 170-01 through 170-18. Each data packet 170 comprises 128 bytes of ADPCM encoded audio data.

Referring to Figure 2B, there is shown the format of one CDROM data block 180 as it is received by the message buffering subsystem 110 whenever it retrieves a block of video or other non-audio data. This format is known in the CDROM industry as the Mode Two, Form One block format. The CDROM data block 180 is preceded by twelve synchronization bytes 181. The CDROM block 160 itself begins with a four byte header 182, including a three-byte address and one mode byte, followed by an eight-byte subheader 184 which specifies the file number, channel number and block type of this particular block. Next there are 2048 bytes of data 186, followed by a four "byte error detection code 187. Finally the block 180 is completed by 276 bytes of error correction code 188.

DE-INTERLEAVING MODE.

Each CDROM block received by the subsystem 110 contains a subheader which denotes a channel number, which is an assigned value between 0 and 31. Different channel numbers are used to logically organize the data on the CDROM 108. For instance, audio data in a particular CDROM file may be stored in blocks marked as being in channel 1, while video data is stored in block marked as being in channel 2. Before starting de-interleaving, the host computer 102 sends to the subsystem a command called SETXA which specifies an audio channel number and also a "channel mask" that specifies which channels are to be used and which are to be ignored.

For example, if the host's SETXA command specifies that only channels 1 and 2 are to be used, and the audio channel is to be channel 1, then any retrieved CDROM block which is not equal to 1 or two is simply ignored. Channel 1 CDROM blocks received by the subsystem 110 are stored in the decoder's static RAM 136 and then played by the decoder 140. Channel 2 CDROM blocks received by the subsystem 110 are temporarily stored in the subsystem's RAM 132 and are then retransmitted to the host computer 102 via the communications bus 104. This process continues until either the end of CDROM file is reached, or the last designated CDROM block has been retrieved.

An alternate method of performing de-interleaving is as follows. The message buffering subsystem 110 plays those audio data blocks which have the specified channel number, and ignores all other blocks. The host 102 monitors the data being transmitted over the SCSI bus 104 by the CDROM drive 106 and retrieves those non-audio data blocks which have a different specified channel number. In this way, the host 102 directly retrieves the data that it needs and thereby avoids the need to have the subsystem 110 retransmit those blocks of data. This method of de-interleaving reduces bus traffic on the SCSI bus 104 and makes bus timing a non-issue. The disadvantage of this methodology is that the host computer 102 is burdened with the task of having to inspect every block of CDROM data that is transmitted. In some applications, that burden is acceptable and in others it is unacceptable. Thus the de-interleaving methodology used by the subsystem 110 will depend on the particular host application that is using the message buffering and decoding subsystem 110.

It may be noted that data is always retrieved from the CDROM 108 at a rate of seventy-five CDROM blocks per second (i.e., one CDROM block is received approximately once every 13.33 milliseconds). Using ADPCM C-MONO encoded audio data, it is possible to interleave fifteen blocks of video or other non-audio data with each CDROM block of audio data.

Within each 13.33 millisecond period used for retrieving one CDROM block, it takes approximately 2.5 milliseconds to transmit the CDROM block itself, and about 2.0 milliseconds for the communications bus 104 to become available for another data transfer. This leaves approximately 8.8 milliseconds after each CDROM block is retrieved to process that data, i.e., to send one portion to the decoder 140 and another portion to the host computer, which is sufficient time that purpose in the preferred embodiment.

In other embodiments there may not be sufficient time during each 13.33 millisecond time period to both retrieve and retransmit a CDROM block of data because the overhead associated with using a SCSI bus. In that case, the alternate embodiment shown in Figure 5 should be used. That alternate embodiment is discussed below.

Referring to Figure 3, the data structures associated with the message buffers 134 shown in Figure 1 are as follows. In the preferred embodiment, there are twenty logical message buffers M01 through M20. Audio data associated with the messages are stored in variable size audio data records 190 (also called message blocks) in the message buffer RAM 134. When the host 102 commands the subsystem 110 to store the compressed audio data from a particular CDROM file, all of the audio data in that file is stored in one message block 190 in the message buffer RAM 134.

A directory 200 of the message blocks includes a set of entries 202-01 through 202-200. For each message block of audio data stored in the message buffer RAM 134, there is an entry 202 which denotes the beginning address and size of that message block 190. The entry 202 also includes a link field 204 which denotes whether there is another message block that is logically concatenated to the end of this message block. In the example shown in Figure 3, logical message M01 is stored in three concatenated message blocks, corresponding to entries 202-01, 202-02, and 202-03.

The message buffering subsystem is set up to handle up to twenty logical messages M01 through M20. For each logical message, there is a pointer 212 stored in a pointer array 210. That is, for each non-empty logical message, there is a non-zero pointer 212 which points to one of the entries 202 in the message block table 200. In the example shown in Figure 3, logical message M02 is stored in the message block pointed to by entry 202-04.

Whenever a logical message is erased, the message blocks for the other logical messages are moved within the RAM 134, if necessary, so that all the "empty" space in the message buffer RAM 134 is in a contiguous portion of addresses. This, of course, requires updating the address portion of the entries 202 for those message blocks that are moved. Also the entries in table 200 for the erased logical message are also erased, and the pointer 212 in array 210 for the erase logical message is cleared.

Furthermore, as shown in Figure 3, the subsystem maintains a pointer 220 to the beginning of the empty space in the message buffer RAM 134. This pointer 220 is updated every time that a message block is either added to the message buffer RAM 134 or deleted.

Whenever a new message block 190 is needed to append a message to a logical message buffer Mxx, empty space from the message buffer RAM 134 is assigned to a unused message block entry 202 in table 200, and the empty space pointer 220 is updated. If this is the first message block 190 for a logical message Mxx, the pointer 212 for that message is set to point to the entry 202 for the new message block 190. If this message block 190 is being appended to an already existing logical message, which means that it is being concatenated to the end of another message block, the link field 204 in the last entry 202 in table 200 for the logical message is set to point to the entry 202 for the new message block.

To enable the host computer 102 to quickly determine the status of each logical message buffer Mxx, the status of each message is denoted in a status array 220. The format of the status information 222 for each message is shown in Table 2.

One additional data structure used for playing messages is a playing queue 230, which is used for listing a sequence of messages that are to be played in sequence. The playing queue 230 is used only when the host 102 requests that one or more messages be played while another message is already playing. All of the queued messages are listed in the queue 230 until the message buffering subsystem 110 can play those messages.

It should be noted that all of the data structures shown in Figure 3, except for the message blocks stored in the message buffer RAM 134, are stored in the subsystem's general purpose RAM 132.

TABLE 2 MESSAGE BUFFER STATUS

Status Information Description

Message Number Integer: 0 to 19

Playing Flag 0=not playing, l=playing

Appending Flag 0=not appending, l*=appending

Buffer Size Number of bytes in message

#Appends Number of appends since message buffer was last cleared

Append Fail Flag 0=append successful l=append fail

Command Error Flag = no error yet

■ already appending

- already playing

■ appending already paused

- playing already paused

- not appending = not playing

= appending not paused = playing, not paused

- empty-message

Append Pause not paused; 1 = paused Play Pause

MESSAGE AND CDROM DATA HANDLING SOFTWARE.

Referring to Figure 4, the ROM 124 shown in Figure 1 stores software used by the microprocessor 120, including a number of routines 250 which correspond to the commands that the host computer 102 can send to the message buffering system 110. The following is a description of those commands. TEST_UNIT_READ . When the message buffering system 110 and the CDROM Drive 106 are both ready, this routine returns a GOOD status; otherwise it returns a CHECK CONDITION status.

REZERO_UNIT. This command causes a general reset of the message buffering system 110. All data structures associated with the message buffers are cleared, the queue 230 is cleared, any messages being played are stopped, and any appending of CDROM data to message buffers is stopped.

NO_OPERATION. This is a time filler, which immediately returns a GOOD status to the host computer 102.

REQUEST_SENSE. Data regarding the status of the buffer subsystem 110 is sent to the host computer 102.

INQUIRY. Data representing the attributes of this device (i.e., the message buffering subsystem 110) are sent to the host computer, including a device type (equal to DBh) , the name of the vendor, a product ID, a revision number and revision date.

SEND_DIAGNOSTIC. This executes a set of self diagnostic tests which determine how well the message buffering system 110 is working.

READ_CAPACITY. A data block indicating the total memory capacity of the message buffers 134 in the message buffering system 110 is sent to the host computer 102.

CONFIGURE. The host computer 102 sends "configuration" data to be stored in the system's RAM 132, the configuration data being indicative ^' of the interface's assigned "device ID" and "logical unit number." CLEAR. This command causes the message buffering system 110 to erase a specified logical message buffer. Playing halts if the specified message buffer is currently being played.

PLAY. This command initiates playing the audio data in a specified message buffer. If another message is currently being played, the specified message is added to the end of the message queue 230.

APPEND_FILE. This command is used to append a specified CDROM audio data file to a specified logical message Mxx. The message buffering system 110 responds to this command by beginning to load audio data from the specified CDROM file into a new message block in the message buffer RAM 134. If the specified logical message already contains data, the data from the file is appended to the end of the logical message. Otherwise the message block in which the specified audio data file is stored becomes the first message block 190 for the specified logical message. This command differs from APPEND in that the source of the data to be loaded is specified by a file name rather than as a sequence of data blocks beginning at a specified address.

APPEND. This command is used to append a specified set of CDROM block to a specified logical message Mxx. The message buffering system 110 loads into a new message block a specified number of CDROM blocks of audio data beginning at a specified logical block address on the CDROM. If the specified logical message buffer already.contains data, the data from the CDROM is appended to the end of the message; otherwise the loaded data becomes the first message block for the specified logical message.

STATUS. A block of data denoting status information about a specified logical message buffer is sent to the host computer 102. The status -data sent is listed in Table 2, discussed above.

STATUS_ALL. For every one of the logical message buffers, the host is sent a block of status information, in the format shown in Table 2.

PAUSE_APPENDING. This command temporarily suspends the loading of sound data from the CDROM, and also releases the message buffering system's device reservation on the CDROM, thereby allowing the host computer 102 to directly access the CDROM.

PAUSE_PLAYING. This command suspends message playing.

RESUME_APPENDING. The message buffering system 110 reserves the CDROM device, and then resumes loading data from the CDROM into message buffers.

RESUME_PLAYING. The message buffering system 110 resumes playing the message that was playing when the PAUSE_PLAYING command was executed.

0

SETXA. This command specifies a file on the CDROM which is to be de-interleaved. It also denotes which channel (see Figure 2) is to be played and which other CDROM channels contain data blocks that are to be transmitted to the host computer.

START_DE-INTERLEAVING. This starts de-interleaving and specifies either (1) the number of blocks that are to be de-interleaved starting at a specified address, or (2) that de-interleaving should continue to the end of the file specified by the SETXA command. One channel of audio data is played while other data from the CDROM are sent to the host. STOP_DE-INTERLEAVING. De-interleaving is stopped.

SEND_SOUNDMAP. When the host sends this command to the message buffering system 110, it is followed by 2304 bytes of ADPCM data which are to be played immediately by the message buffering system 110 at a specified volume level. The transmitted audio data has a playing time of about one fifth of a second.

APPEND_SOUNDMAP. When the host sends this command to the message buffering system 110, it is followed by 2304 bytes of ADPCM data which are to be appended to a specified message buffer.

CONCATENATE. This instructs the subsystem 110 to concatenate a first specified logical message to the end of a second specified logical message. As a result, the first specified logical message ceases to exist and the second specified logical message becomes longer.

ALTERNATE EMBODIMENTS.

Referring to Figure 5, a second embodiment of the message buffering system 300 is designed to ensure that non-audio data can be retransmitted by the subsystem 310 to the host 102 regardless of the activity level on the communications bus between the subsystem 310 and the CDROM drive 106. In the first preferred embodiment described above, during de-interleaving either (1) the host directly reads in non-audio data as it is transmitted by the CDROM, or (2) the subsystem 110 temporarily stores each non-audio ata block transmitted by the CDROM 106 and retransmits it to the host 102 during the portion of each 13.33 millisecond period that is not used for transmitting a CDROM block from the CDROM drive 106 to the subsystem 110. In some circumstances, there may not be enough time for retransmitting data blocks to the host 102 using a single SCSI bus. Therefore, in this alternate embodiment, the message buffer subsystem 310 uses separate SCSI busses 302 and 304 to couple the subsystem 110 to the CDROM drive 106 and to the host 102. For each separate bus 302 and 304 there is a separate SCSI bus interface 312 and 314, respectively.

Referring to Figure 6, in another alternate embodiment of the message buffering system 350, the message buffering system handles the functions of both a host computer and a message buffering system. Thus, the CPU 120 is not coupled to a host computer. Instead, it has the standard peripherals for a computer system, such as a disk drive 352, display 354, and keyboard 356. Depending on the computational load to be placed on the system 350, the CPU 120 of the message buffering system may be replaced with a more powerful microprocessor, such as an 80286 made by Intel.

The ROM 124 still contains all the message buffering software routines described above. In addition, it contains application software 360 for performing a predefined function, such as simulating the operation of an airplane. The application software 360 calls the message buffering subroutines described above for retrieving messages from the CDROM 108 and storing them in message buffers, and for retrieving other data from the CDROM 108.

It is important to note that the CDROM 108 and CDROM drive 106 in the preferred embodiments may be replaced with other types of random access memory media, such as a standard magnetic disk and disk drive, a WORM drive, or a computer network that is coupled to memory media at other nodes on the network. In general, the message, buffering system and method of the present invention is intended to provide an intelligent buffer for audio data that is stored on a slower media than standard RAM chips. While the present invention has been described with reference to a few specific embodiments, the description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. An audio message decoding and buffering system, comprising: message buffer means for storing a multiplicity of encoded audio messages; said message buffer means having a predefined access rate at which the contents of said message buffer means can be read and written; decoder means, coupled to said message buffer means, for decoding specified ones of said encoded audio messages stored in said message buffer means, thereby generating audio signals corresponding to said audio messages; and data processing means coupled to said message buffer means, said decoder means, and to a data storage medium which stores data including encoded audio messages; said data storage medium having a predefined access rate which is significantly slower than the access rate of said message buffer means; said data processing means comprising means for retrieving data from said data storage medium, said retrieved data including specified encoded audio messages; said data processing means including software means for storing a multiplicity of specified encoded audio messages retrieved from said data storage medium in said message buffer means, and for sending specified ones of said stored encoded audio messages to said decoder means so as to generate corresponding audio signals.

2. An audio message decoding and buffering system as set forth in Claim 1, said data storage medium storing encoded audio data at predefined locations within said data storage mediu ; said message buffer means including means for associating a logical message number with each encoded audio message stored in said message buffer means; said software means further including means for retrieving encoded audio data from specified locations within said data storage ^"medium and for appending said retrieved audio data to encoded audio data stored in said message buffer for a specified logical message number.

3. An audio message decoding and buffering system as set forth in Claim 1, said software means further including means for concatenating specified ones of said encoded audio messages stored in said message buffer means; whereby a plurality of encoded audio messages can be concatenated so as to form one or more audio messages which are longer in duration that each of said concatenated encoded audio messages.

4. An audio message decoding and buffering system, comprising: message buffer means for storing a multiplicity of encoded audio messages; decoder means, coupled to said message buffer means, for decoding specified ones of said encoded audio messages stored in said message buffer means, thereby generating audio signals corresponding to said audio messages; and data processing means, coupled to a host computer and a CDROM by a communications bus, and coupled to said message buffer means and decoder means by a local system bus, said communications bus transmitting commands sent by said host to said data processing means and transmitting data retrieved from said CDROM to said data processing means; said data processing means including software means for storing a multiplicity of specified encoded audio messages retrieved from said CDROM in said message buffer means, and for sending specified ones of said stored encoded audio messages to said decoder means so as to generate corresponding audio signals.

5. An audio message decoding and buffering system as set forth in Claim 4, said CDROM storing encoded audio data at predefined locations on said CDROM; said message buffer means including means for associating a logical message number with each encoded audio message stored in said message buffer means; said software means further including means for retrieving encoded audio data from specified locations on said CDROM and for appending said retrieved audio data to encoded audio data stored in said message buffer for a specified logical message number.

6. An audio message decoding and buffering system as set forth in Claim 4, said CDROM storing blocks of data, each block being stored at a predefined location on said CDROM, said CDROM including a multiplicity of data blocks containing encoded audio data which are interleaved with data blocks containing non-audio data; said data processing means including means for retrieving a sequence of said interleaved data blocks from said CDROM, sending at least a portion of said retrieved audio data to said decoder means, and transmitting at least a specified portion of said non-audio data to said host computer.

7. An audio message decoding and buffering system, comprising: message buffer means for storing a multiplicity of encoded audio messages; decoder means, coupled to said message buffer means, for decoding specified ones of said encoded audio messages stored in said message buffer means, thereby generating audio signals corresponding to said audio messages; and data processing means, coupled to a CDROM, said message buffer means and decoder means, for retrieving data from said CDROM, said retrieved data including specified encoded audio messages; said data processing means including software means for storing a multiplicity of specified encoded audio messages retrieved from said CDROM in said message buffer means, and for sending specified ones of said stored encoded audio messages to said decoder means so as to generate corresponding audio signals.

8. An audio message decoding and buffering system as set forth in Claim 1 , said CDROM storing encoded audio data at predefined locations on said CDROM; said message buffer means including means for associating a logical message number with each encoded audio message stored in said message buffer means; said software means further including means for retrieving encoded audio data from specified locations on said CDROM and for appending said retrieved audio data to encoded audio data stored in said message buffer for a specified logical message number.