Dynamic Scaling of CPU Cycle Consumption in a Computer System

3. Art Background

Computer systems commonly employ communication input/output subsystems that enable modem or fax communication over a telephone line. Some prior communication subsystems enable both fax and data modem transfers over a common telephone line. A communication subsystem that enables both modem and fax transfers is commonly referred to as a fax-modem.

Such prior communication subsystems typically contain a digital signal processor central processing unit (DSP-CPU) for executing telephony hardware driver software, and telephony control hardware for physically driving the telephone line. Typically, such communication subsystems implement a read only memory (ROM) based telephony hardware driver. The telephony hardware driver usually receives control messages and data from the host computer, and performs the required hardware control functions to transfer information over the telephone line.

A computer system may implement a multi-function input/output (I/O) subsystem that provides multi-tasking for a variety of I/O functions. For example, such a multi-function I/O subsystem may include telephony hardware that enables data modem and fax transfers over a telephone line and audio hardware that enables audio I/O functions.

One drawback of such a multi-tasking I/O subsystem is that certain I/O tasks require large amounts of CPU time. Such tasks are typically assigned the highest priority for execution. For example, a modem data transfer task is usually assigned a high priority. In general, the high priority I/O intensive tasks typically consume large amounts of CPU cycles or MIPS (millions of instructions per second).

Unfortunately, such high priority I/O intensive tasks can consume most of the MIPS available in the system. The lower priority I/O tasks in such a system may not receive enough MIPS to properly execute. As a consequence, the lower priority tasks I/O tasks are subject to real-time errors. For example, a low priority audio recording task is subject to real-time errors during audio data gathering while a high priority data modem task is consuming most of the available MIPS during a high baud rate file transfer. Such real-time errors during audio recording typically result in poor quality audio reproduction.

Some real time systems, and non-real time systems, attempt to provide a measure of CPU consumption which is based on a calculation of CPU cycles not spent in an "idle" state. However, such measures do not adequately indicate actual CPU utilization for real time systems because some tasks not real time limited by I/O may consume all spare CPU cycles when executing. In such a case, a 100% CPU utilization indication only means that some task is using all spare cycles but does not indicate whether a high MIPS consumer should scale MIPS consumption.

One object of the present invention is to provide a real time reporting system that indicates that some I/O task is not receiving enough CPU cycles and thereby enable the scaling of MIPS consumption.

A computer system is disclosed that dynamically scales consumption of processor cycles by input/output tasks. A performance task in the computer system determines an error measure that indicates a number of real-time errors logged by at least one input/output driver in the system. If the error measure exceeds a predetermined threshold, then the consumption of processor cycles by a high MIPS consumption task is scaled back or reduced. Input/output drivers log real-time errors upon detection of, for example, buffer overruns that occur during data sampling. For one embodiment, the error measure is determined by averaging the number of real time errors logged by the input/output drivers during a predetermined time interval.

For one embodiment, the input/output drivers and tasks and the performance monitor are implemented on a multi-function input/output subsystem that includes a CPU that executes the input/output drivers and tasks along with a multi-tasking operating system. For another embodiment, the input/output drivers and tasks and the performance monitor are executed by the host processor in the computer system.

Other features and advantages of the present invention will be apparent from the accompanying drawings, and from the detailed description that follows below.

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements, and in which:

FIG. 1 illustrates a system including a personal computer that receives incoming calls and transmits outgoing calls over a telephone line and that enables audio record and playback functions;

FIG. 2 illustrates a computer system which comprises a host processor, a memory subsystem, a mass storage subsystem, and a multifunction I/O subsystem;

FIG. 3 illustrates one embodiment of a multifunction I/O subsystem that includes a DSP processor and which provides an analog phone line interface circuit and associated codec circuits, and a stereo audio codec circuit;

FIG. 4 illustrates a multitasking input/output software system that provides dynamic scaling of MIPS consumption;

FIG. 5 illustrates the software architecture for the host processor and the multifunction I/O subsystem for the embodiment shown in FIG. 3;

FIG. 6 illustrates interaction between a host device driver executing on the host processor and a corresponding DSP-OS task that executes on the DSP CPU of the multifunction I/O subsystem in one embodiment;

FIG. 7 illustrates a software architecture of the host processor including application programs that enable telephony functions and audio functions;

FIG. 8 illustrates a software architecture of the multifunction I/O subsystem for the embodiment shown in FIG. 3;

FIG. 9 illustrates another embodiment of a multifunction I/O subsystem that includes an analog phone line interface and associated circuits, and a stereo audio codec circuit;

FIG. 10 illustrates a software architecture of the host processor for the embodiment of the multifunction I/O subsystem shown in FIG. 9 wherein host tasks and I/O tasks are executed by the host processor.

FIG. 1 illustrates a computer system 10 for one embodiment. The computer system 10 includes a personal computer 12 that receives incoming calls and transmits outgoing calls over a telephone line 22. The telephone line 22 comprises a standard telephone line or alternatively a private branch exchange (PBX) line or ISDN connection. A microphone 11 and a set of speakers 18 and headphones 19 enable audio input/output for the personal computer 12.

FIG. 2 illustrates the personal computer 12. The personal computer 12 comprises a host processor 32, a memory subsystem 31, a mass storage subsystem 33, and a multifunction I/O subsystem 14. The host processor 32, the memory subsystem 31, and the multifunction I/O subsystem 14 communicate over a host bus 44.

The multifunction I/O subsystem 14 provides sound capture/playback functions, fax and data modem functions, and telephone control functions. The multifunction I/O subsystem 14 provides connections for microphones and speakers, and hardware to support telephone and telephone line connections.

The mass storage subsystem 33 represents a wide variety of mass storage devices for large scale data and program storage, including magnetic disk drives and CD ROM drives.

FIG. 3 illustrates one embodiment of the multifunction I/O subsystem 14 that includes a digital signal processor (DSP) 61. The multifunction I/O subsystem 14 further comprises an analog phone line interface circuit 60 and associated codec circuits (a .mu.-law codec 70 and a linear codec 72), a stereo audio codec circuit 54, and a set of interface circuits 63-69.

A memory block 62 comprises a DSP static random access memory (SRAM) and a DSP dynamic random access memory (DRAM). Both DRAM and SRAM can be used for program or data. The bus interface circuit 67 and the DMA arbiter circuit 65 enable the DSP 61 to communicate over the host bus 44.

The analog phone line interface circuit 60 and the .mu.-law and linear codec circuits 70 and 72 enable transfer of incoming and outgoing calls over the local line 20 and the telephone line 22 including full duplex connections between the .mu.-law codec 70 and the telephone 15 and full duplex connections between linear codec 72 and the telephone line 22. The .mu.-law phone and linear line codec circuits 70 and 72 transfer digital data to and from the DSP 61 through the phone interface circuit 66.

The stereo audio codec circuit 54 transfers audio signals (mono and stereo) to the external speakers 18 and the headphone set 19 over a set of audio signal lines 56. The stereo audio codec circuit 54 also receives audio signals (mono and stereo) from an audio source and external microphone 14 over a set of audio signal lines 58. The stereo audio codec circuit 54 performs analog-to-digital conversion on the received audio signals, and transfers the digitized audio data to the audio interface (I/F) circuit 68. The stereo audio codec circuit 54 performs digital-to-analog conversion on audio data received through the audio interface (I/F) circuit 68.

For one embodiment, the multifunction I/O subsystem 14 comprises an industry standard architecture (ISA) add-in card that provides hardware to support audio and telephony applications.

FIG. 4 illustrates a multitasking input/output system that provides dynamic scaling of MIPS consumption. The multitasking input/output system provides a set of input/output software including a MIPS burning task 71 and a corresponding driver task 73, along with a MIPS starved task 72 and a corresponding driver task 74.

The MIPS burning task 71 consumes high amounts of CPU cycles during input/output functions. The MIPS burning task 71 performs data transfers to and from the input/output circuitry 75 through the driver task 73. The high MIPS consumption of the MIPS burning task 71 causes the MIPS starved task 72 to suffer from real-time errors. The real-time errors are encountered by the driver task 74 during data transfers to and from the input/output circuitry 76.

The multitasking input/output system includes a performance monitor task 70 that determines an error measure that indicates real-time errors encountered by the driver tasks 73 and 74. The driver tasks 73 and 74 each log real-time errors in a real-time error log 77. The performance monitor task 70 reads the real-time error log 77 and calculates the error measure using, for one embodiment, a time-average of errors recorded in the real-time error log 77 during a predetermined time interval.

The MIPS burning task 71 periodically queries the performance monitor task 70 for the error measure and then takes the appropriate action required by the indicated rate of errors including the scaling back of MIPS consumption.

FIG. 5 illustrates the software elements for the host processor 32 and the multifunction I/O subsystem 14 for one embodiment. A set of application programs 100-102 executing on the host processor 32 access the hardware functions of the multifunction I/O subsystem 14 through an application program interface (API) 104-106.

An application program interface consists of a dynamic link library (DLL) layer and a corresponding host device driver. The dynamic link library layer interacts with host application programs that use the corresponding application program interface. The dynamic link library layer performs error checking and translates application program calls into messages that are passed to the appropriate device driver.

For example, the application program interface 104 provides dynamic link library 109 that links at runtime to a host device driver that communicates with a hardware device in the multifunction I/O subsystem 14. The dynamic link library 109 translates the application program interface 104 calls into messages that are passed to the device driver which performs the requested function.

The dynamic link library layers 107-109 of the application program interfaces 104-106 interact with one or more host device drivers 110-114 via common device driver interfaces 115-117. The host device drivers 110-114 are implemented as dynamic link libraries. A set of device-type specific custom messages are defined by the device driver for the corresponding device class.

The code for the application program interfaces 104-106 comprises the dynamic link libraries 107-109. The application programs 100-102 that require the services provided by the application program interfaces 104-106 link against the library corresponding to the corresponding dynamic link library 107-109.

The dynamic link libraries 107-109 translate application program interface calls into host device driver calls or messages. The host device driver calls or messages and associated data structures define the device driver interface (DDI) for the corresponding device class. A host device driver for an application program interface is provided by implementing the corresponding DDI.

The multifunction I/O subsystem 14 implements a digital signal processing operating system (DSP-OS) that executes on the DSP 61. The DSP-OS enables multiple concurrent execution of audio and telephony tasks (such as a DSP-OS task 132 and a DSP-OS task 134) on the multifunction I/O subsystem 14.

The DSP-OS is a real time multitasking operating system that provides two programing interfaces: the application programming interface and a system programming interface (SPI). The DSP-OS application program interface provides a set of high-level processor independent functions for computations by the DSP 61, as well as stream input and output to the multifunction I/O subsystem 14.

The software for the multifunction I/O subsystem 14 includes a set of DSP device drivers 130 and 135-137. The DSP-OS tasks 132-134 perform computations and I/O to devices via the DSP device drivers 135-137.

A typical DSP-OS task reads input data from a hardware device, processes the input data, and then writes output data to another hardware device. Normally, multiple DSP-OS tasks perform such processes concurrently. A DSP device driver enables the DSP-OS tasks to access hardware devices. Each hardware device corresponds to a DSP device driver that manages the hardware device and provides I/O services to the DSP-OS tasks.

The DSP-OS system programming interface provides a set of functions for managing DSP-OS tasks, and for managing the DSP memory 62. The DSP-OS system programming interface provides functions for synchronizing DSP-OS tasks, and functions for performing device-independent I/O.

The host device drivers 110-114 communicate with DSP programs executing on the multifunction I/O subsystem 14 through a DSP interface 120. For example, a host audio device driver uses the DSP interface 120 to control a DSP-OS task that manages data transfer to and from the stereo audio codec circuit 54. The host audio device driver can communicate with several DSP-OS tasks. A DSP-OS task created by a host device driver may create other DSP-OS tasks to provide the appropriate hardware functions.

The DSP interface 120 is message-based. The DSP interface 120 defines a common structure for messages and a programming model for communication between host device drivers and corresponding DSP-OS tasks. Each host device driver defines an appropriate set of message formats (such as command codes, parameters, status and reply codes, etc.) for communication with the corresponding DSP-OS task.

A host DSP driver 122 implements the DSP interface 120. The host DSP driver 122 comprises a dynamic link library (DLL) that enables communication with the multifunction I/O subsystem 14. The host DSP driver 122 loads the DSP-OS and starts the DSP 61 to initialize the multifunction I/O subsystem 14 and run the DSP-OS. After the multifunction I/O subsystem 14 is initialized and the DSP-OS is running, the host DSP driver 122 moves buffers of data and messages between the host processor 32 and the multifunction I/O subsystem 14.

The host DSP driver 122 communicates with a DSP host driver 130 executing under the DSP-OS. The host DSP driver 122 and the DSP host driver 130 do not examine the content of the data and messages passed over the hardware interface 125. The host DSP driver 122 and the DSP host driver 130 synchronize multiple data and message streams and route each stream to the appropriate host device driver and DSP-OS task.

A DSP-OS server 124 executing on the host processor 32 functions as a server for the DSP-OS tasks 132-134 and 146. The DSP-OS server 124 processes requests from the multifunction I/O subsystem 14. The DSP-OS server 124 is a "daemon" on the host processor 32. The DSP-OS server 124 is a part of the host DSP driver 122. The DSP-OS server 124 services file and console I/O requests from the DSP-OS tasks 132-134 and 146 to the host processor 32. The DSP-OS server 124 assists in dynamic DSP-OS task loading, and provides a user interface for status and performance monitoring of the multifunction I/O subsystem 14.

The DSP-OS is a real-time multitasking operating system that provides a kernel and input/output (I/O) environment for the software executing on the multifunction I/O subsystem 14. The DSP-OS defines a set of device-independent I/O interface 140-143 for use by the DSP-OS tasks 132-134 and 146 to access hardware devices of the multifunction I/O subsystem 14. The DSP-OS also defines stackable device drivers which are blocks of code that provide common (i.e., reusable) transformations on I/O streams in the standard format.

A DSP program executing on the DSP 61 functions as a server for a corresponding client host device driver on the host processor 32. A DSP program performs the commands requested by the client host device driver through the appropriate messages.

A DSP program consists of one or more DSP-OS tasks that move data from source devices to sink devices, while performing specific processing and transformations on the data. For example, an audio DSP-OS task reads audio samples from the stereo audio codec circuit 54 using a device independent I/O interface, processes the samples to perform data compression, and then transfers the compressed data to the host audio device driver executing on the host processor 32.

The DSP-OS creates a DSP-OS dispatcher task 146 after starting up. The DSP-OS dispatcher task 146 processes requests from the host device drivers 110-114 to create and delete DSP-OS tasks. The DSP-OS dispatcher task 146 matches a task name to the appropriate DSP-OS tasks and then loads and starts the new DSP-OS tasks. The DSP-OS dispatcher task 146 also creates mailboxes for communications between the requesting host device driver or other DSP-OS tasks and the new DSP-OS task.

The functions of a DSP-OS task are controlled by placing messages in a corresponding mailbox. The interpretation of the messages follows a device-class specific protocol. Each DSP-OS task recognizes a small set of basic messages.

FIG. 6 illustrates interaction between a host device driver 180 executing on the host processor 32 and a corresponding DSP-OS task 182 for one embodiment. The host device driver 180 controls and communicates with the DSP-OS task 182 via a control channel and one or more data channels.

The DSP interface 120 provides the control channel that enables the host device driver 180 to send messages to the DSP-OS task 182, and receive messages from the DSP-OS task 182. The control channel is implemented according to a mailbox facility. The host device driver 180 calls a dspOpenTask routine to create the DSP-OS task 182, and to create a pair of mailboxes 184-185. The host device driver 180 and the DSP-OS task 182 use the mailboxes 184-185 to exchange messages.

Large data transfers between the host device driver 180 and the DSP-OS task 182 are subdivided into blocks according to a buffer size specified for the host device driver 180. The control channel messages are interleaved with data blocks.

The host device driver 180 and the DSP-OS task 182 exchange data through one or more data streams. A data stream is a channel that provides data flow in one direction between a host device driver and a DSP-OS task. Two data channels are employed to exchange data in both directions, i.e. from the host device driver 180 to the DSP-OS task 182 and from the DSP-OS task 182 to the host device driver 180.

The DSP interface 120 supplies a uniform set of services for communication with the multifunction I/O subsystem 14. For one embodiment, the DSP interface 120 supplies the communication services for the multifunction I/O subsystem 14 in a Microsoft.RTM. Windows environment. The services are employed by the application programs 100-102 and the host device drivers 110-114.

Each host device driver 110-114 starts and stops at least one DSP-OS task, and transfers data streams to and from the DSP-OS task. The DSP interface 120 is optimized for efficient data streaming to the DSP-OS task. The DSP interface 120 enables command message transfer between the host device drivers 110-114 and the DSP-OS tasks.

The DSP interface 120 also provides basic control functions for the multifunction I/O subsystem 14. The control functions are employed by the DSP-OS server 124. The control functions provided by the DSP interface 120 include control functions for loading the DSP-OS program image, control functions for starting and stopping the DSP 61, as well as control functions for obtaining diagnostic and status information from the multifunction I/O subsystem 14.

An application executing on the DSP 61 consists of one or more DSP-OS tasks that typically performs computations. A DSP-OS task has an associated host device driver that functions as a server. The host device driver launches the DSP-OS tasks (via a call to dspOpenTask) and thereafter sends commands to the newly launched DSP-OS tasks. The DSP-OS tasks service requests from the corresponding host device driver. A host device driver and a corresponding DSP-OS task have a client/server relationship.

The DSP-OS tasks are created through the DSP-OS dispatcher task 146. The DSP-OS dispatcher task 146 is a special DSP-OS task created when the system starts up. The DSP-OS dispatcher task 146 communicates with the host DSP driver 122. The DSP-OS dispatcher task 146 sets up the DSP-OS environment on the multifunction I/O subsystem 14 and then assumes the role of a central control DSP-OS task. The DSP-OS dispatcher task 146 responds to a set of command messages from the host device drivers, including requests to create and delete a DSP-OS task.

The DSP-OS tasks send data to the host device drivers, and receive data from the host device drivers. A data streaming interface enables efficient transmission of data blocks (buffers). The data streaming interface is accessed through the DSP-OS. The host application programs access the data channels between a DSP-OS task and the corresponding host device driver through the host device driver. The DSP-OS tasks access files on the mass storage subsystem 33 through a corresponding host device driver.

The DSP-OS supports device independent I/O by providing a common set of functions used to access the differing hardware devices of the multifunction I/O subsystem 14 in a uniform manner. The DSP device drivers 130 and 135-137 implement the DSP-OS device-independent I/O interfaces 140-143 to enable access of the hardware devices of the multifunction I/O subsystem 14. The DSP-OS tasks 132-134 and 146 employ the device-independent I/O interfaces 140-143 to transfer data to or from any hardware device of the multifunction I/O subsystem 14 as a source or a sink.

The DSP-OS tasks 132-134 and 146 read input data from a source device, processes the input data, and then write the processed data to a sink device. An SS.sub.-- get and an SS.sub.-- put operation are used for such processing. The local line 20, the telephone line 22, the stereo audio codec circuit 54, and the hardware devices of the host processor 32 are available as sources and sinks. The mass storage subsystem 33 functions as multiple sinks and multiple sources simultaneously, such that multiple logical data channels are concurrently active.

The multifunction I/O subsystem 14 provides hardware devices that support multiple application program interfaces. For example, the stereo audio codec circuit 54 is employed for sound file input and output through an audio application program interface, and for telephone conversations through a telephony application program interface. The telephone line 22 is employed for telephone conversations through the telephony application program interface, for sending and receiving faxes through a fax application program interface, and for data modem processing. In all such cases, the particular hardware device is accessed via the DSP-OS device-independent I/O interface.

The hardware devices of the multifunction I/O subsystem 14 that generate and consume sampled sound data streams represent the sampled sound data in differing data formats. A hardware device or DSP device driver may represent sound data in amplitude normalized format, wherein the sound samples comprise 32-bit floating point left justified data values that are scaled to range from -2**31 to 2**31-1 for conversion to 32-bit signed integers.

A hardware device or DSP device driver may represent sound data as 32-bit floating point right justified data values, wherein 8-bit sound samples range from -256 to 255 and 16-bit sound samples range from -32768 to 32767. A hardware device or device driver may represent sound data as 16-bit signed integer right justified data values with one sample per 32-bit word, wherein sound samples range from -32768 to 32767.

A hardware device or DSP device driver may represent sound data as packed 16-bit integer data values, wherein a 32-bit word either represents left and right samples (stereo) or two successive samples (mono). In addition, 8-bit .mu.-law samples are packed four to a 32-bit word.

DSP-OS tasks employ a standard data format to represent sampled sound data streams for the multifunction I/O subsystem 14. The standard data format is 32-bit floating-point left-justified. The sound data stream samples are scaled to range between -2**31 an 2**31-1. Such scaling enables efficient conversion between floating point and integer data formats.

The standard data format supports a range of +/-(2).sup.127. However, sound sample values having a magnitude greater than 2.sup.31 generate erroneous results if sent to a hardware device of the multifunction I/O subsystem 14. Also, sound sample values having a magnitude less than 2.sup.15 are equivalent to 0.

For example, the DSP device driver for the stereo audio codec 54 receives standard data format samples from a corresponding DSP-OS task, converts the standard data format samples into 32-bit integers, then right-shifts the 32-bit integers by 16 bits to extract the high-order 16 bits, and then writes the high-order 16 bits to the stereo audio codec 54.

For another example, a DSP device driver for telephony converts standard data format sound samples into to 8-bit .mu.-law samples by converting the standard data format sound samples into 32-bit integers, then extracting the high-order 14 bits and converting the high-order 14 bits to 8-bit .mu. law.

The standard data format for sampled sound data streams enables the DSP-OS tasks to open and read sound samples from multiple hardware devices that require differing data formats. Similarly, the standard data format for sampled sound data streams enables the DSP-OS tasks to write sound samples to multiple hardware devices that require differing data formats.

The standard data format for sampled sound data streams also enables the DSP-OS tasks to communicate with devices that generate the same data format with differing scaling. For example, the stereo audio codec 54 generates true 16-bit integer samples that range from -32768 to 32767, while the DSP device driver for the telephone line 22 converts 8-bit .mu. law sound samples into a linear integer format having a 14-bit range (-4096 to 4095). The standard data format for sampled sound data streams enables compatibility if the sound samples for the telephone line 22 are left justified and the extra least significant bits set to zero.

FIG. 7 illustrates the software architecture of the host processor 32 for one embodiment. The host application programs on the host processor 32 comprise a host telephony application program 200 and a host audio application program 202.

The host telephony application program 200 enables origination and reception of voice calls, data modem calls, and fax calls over the telephone line 22. The host telephony application program 200 performs high-level user interface functions and telephony handshake functions for handling the voice, data modem, and fax transfers over the telephone line 22.

The host telephony application program 200 communicates with a host phone control driver 160 and a host fax-modem driver 166 through a telephony application program interface 170. The host phone control driver 160 and the host fax-modem driver 166 communicate with corresponding DSP-OS tasks on the multifunction I/O subsystem 14 through the DSP interface 120 of the host DSP driver 122.

The telephony application program interface 170 provides telephony control services to the telephony application program 200. The telephony application program interface 170 provide services for handling inbound calls, for initiating outbound calls, for accessing features provided by the analog phone line interface circuit 70, and for communicating with remote equipment.

A fax application program interface 172 provides a set of fax control operations to the telephony application program 200. The fax application program interface 172 provides operations for managing incoming and outgoing faxes.

The host audio application program 202 enables recording and playback of sound files. The audio application program 202 enables transfer of information between sound files on the mass storage subsystem 33 and the speakers 18 and the headphones 19 coupled to the audio signal lines 56.

The host audio application program 202 communicates with a host audio driver 164 through an audio application program interface 171. The host audio driver 164 communicates with corresponding DSP-OS tasks on the multifunction I/O subsystem 14 through the DSP interface 120 of the host DSP driver 122.

The functions provided by the audio application program interface 171 include querying audio devices, opening and closing audio devices, recording and playing audio data, and controlling playback and recording.

For one embodiment, the audio application program interface 171 comprises a Waveform application program interface provided by Microsoft.RTM. Corporation for processing Waveform sound files. The Waveform application program interface is part of Microsoft.RTM. Windows. The Waveform application program interface provides sound record and playback functions to Microsoft.RTM. Windows host applications.

FIG. 8 illustrates the software architecture of the multifunction I/O subsystem 14 for one embodiment. A DSP-OS dispatcher task 146 processes requests from the host phone control driver 160, the host audio driver 164 and the host fax-modem driver 166 to create and delete DSP-OS tasks.

The DSP-OS dispatcher task 146 matches the requested task name to the appropriate DSP-OS tasks and then loads and starts the new DSP-OS tasks. The DSP-OS dispatcher task 146 also creates mailboxes for communications between the host phone control driver 160 and the host fax-modem driver 166 and corresponding DSP-OS tasks. The DSP-OS dispatcher task 146 also creates mailboxes for communications between the host audio driver 164 and a corresponding DSP-OS task. The DSP-OS dispatcher task 146 also creates mailboxes for communications between the new DSP-OS tasks and other DSP-OS tasks.

A performance task 320 provides performance monitoring services for DSP-OS drivers and tasks. The performance task 320 provides real-time error logging and real-time error reporting functions for the DSP-OS drivers and tasks. The real-time error logging functions enable DSP-OS drivers to log real-time errors caused by exhaustion of available MIPS of the DSP 61.

The real-time error logging functions also enable the DSP-OS tasks that own the DSP-OS drivers to log real-time errors caused by exhaustion of available MIPS of the DSP 61. The DSP-OS tasks optionally query the corresponding DSP-OS drivers for real-time errors. Low priority DSP-OS tasks can disable logging of the real-time errors reported by the corresponding DSP-OS drivers. The selective enabling and disabling of real-time error logging by the DSP-OS tasks may be used to prevent selected low priority DSP-OS tasks from causing dynamic MIPS scaling in a higher priority DSP-OS task.

The performance task 320 determines a real-time error measure by smoothing the error logging information received from the DSP-OS drivers. The real-time error reporting functions enable DSP-OS tasks to retrieve the real-time error measure.

For one embodiment, the DSP-OS drivers log real-time errors by calling an error logging function of the performance task 320. The DSP-OS tasks perform error logging by periodically querying the corresponding DSP-OS driver or drivers. The DSP-OS tasks then log any real-time errors reported by the queried DSP-OS drivers by calling the error logging function of the performance task 320.

For another embodiment, the DSP-OS drivers log real-time errors by incrementing a global error count variable that is monitored by the performance task 320. The DSP-OS tasks perform error logging by periodically querying the corresponding DSP-OS driver or drivers and then incrementing the global error count variable of the performance task 320 according to the real-time errors reported by the queried DSP-OS drivers.

For one embodiment, the performance task 320 determines the real-time error measure by averaging the number of real-time errors logged by the DSP-OS drivers over a predetermined time interval. The performance task 320 periodically updates the real-time error measure. For example, the performance task 320 executes once each second and updates the real-time error measure by averaging the real-time errors logged during the previous one second interval. Alternatively, five and ten second time intervals are also suitable.

The DSP-OS tasks execute calls to the performance task 320 to retrieve the real-time error measure. High priority DSP-OS tasks use the real-time error measure to determine whether the available MIPS of the DSP 61 are being exhausted. A high priority DSP-OS task can accordingly take steps to reduce MIPS consumption. In addition, the DSP-OS dispatcher task 146 can prevent the launching of more DSP-OS tasks if the real-time error measure is maintained above a predetermined level. The DSP-OS dispatcher task 146 can also cause the host operating system to notify the user that the multifunction I/O subsystem is being overdriven by DSP-OS tasks.

A DSP file input/output (FIO) driver 270 enables access the host processor 32 file system by the DSP-OS tasks. The DSP-OS tasks use the DSP FIO driver 270 to perform open, read, write, and close operations, and to transfer data to and from files on the host processor 32 including files on the mass storage device 33.

The host phone control driver 160 and the host fax-modem driver 166 cause the DSP-OS dispatcher task 146 to create a set of modem DSP-OS tasks 310-314 for processing of data modem transfers over the telephone line 22. The host phone control driver 160 and the host fax-modem driver 166 communicate with the modem DSP-OS tasks 310-314 through a modem port driver 300. The modem port driver 300 implements a modem interface for the host telephony drivers. The modem port driver 300 communicates with the modem DSP-OS tasks 310-314 through the device independent I/O interface.

The modem DSP-OS tasks 310-314 perform telephony functions through a DSP telephony driver 282. The DSP telephony driver 282 communicates through the phone interface circuit 66 to the analog phone line interface circuit 60 and the codec circuits 70 and 72. The DSP telephony driver 282 is driven by interrupts generated by the phone interface circuit 66.

The attention to modem (ATM) command task 310 receives modem control commands from the host phone control driver 160 and the host fax-modem driver 166 through the modem port driver 300. The ATM command task 310 manages the data pump manager task 312 and the modem data pump task 314. The ATM command task 310 initially sets the baud rate for an outbound modem data transfer sequence.

The data pump manager task 312 functions as a server for the host phone control driver 160 and the host fax-modem driver 166. The data pump manager task 312 performs the commands requested by the host phone control driver 160 and the host fax-modem driver 166 according to messages routed through the corresponding mailboxes.

During outbound modem data transfer, the data pump manager task 312 receives an outbound modem data stream from the modem port driver 300. The data pump manager task 312 converts the outbound modem data stream into the standard data format. The data pump manager task 312 feeds the outbound modem data stream to the modem data pump task 314.

The modem data pump task 314 modulates the outbound modem data stream from the data pump manager task 312. The modem data pump task 314 transfers the modulated modem data stream to the telephony driver 282 through the device independent I/O interface. The telephony driver 282 converts the modulated modem data stream from the standard format into a format required by the codecs 70 and 72 and the analog phone line interface 60.

During inbound modem data transfer, the telephony driver 282 gathers line data through the codecs 70 and 72 and the analog phone line interface 60. The telephony driver 282 converts the data samples into an input modem data stream having the standard format. The telephony driver 282 transfers the standard format input modem data stream to the modem data pump task 314. The modem data pump task 314 demodulates the data samples and transfers the input modem data stream to the data pump manager task 312. The data pump manager task 312 transfers the input modem data stream to the modem port driver 300 through the device independent I/O interface. The modem port driver 300 transfers the input modem data stream to the host phone control driver 160 and the host fax-modem driver 166.

For one embodiment, the data pump manager task 312 periodically executes a call to the performance task 320 to retrieve the real-time error measure. If the real-time error measure exceeds a predetermined threshold error count, then the data pump manager task 312 renegotiates the baud rate for the modem data transfer sequence underway. For another embodiment, the modem data pump task 314 periodically execute a call to the performance task 320 to retrieve the real-time error measure and to determine whether the real-time error measure exceeds the predetermined threshold error count.

For example, a modem data transfer sequence at a baud rate of 14,400 could consume most of the available MIPS of the DSP 61 because the data pump manager task 312 and the modem data pump task 314 are assigned the highest priority by the DSP-OS dispatcher task 146. If the real-time error measure indicates that DSP drivers are reporting a significant number of real-time errors, then the data pump manager task 312 or the modem data pump task 314 renegotiates the baud rate for the modem transfer underway down to 9600 or 4800 baud. The reduced baud rate increases the available MIPS of the DSP 61 for the lower priority DSP tasks. The data pump manager task 312 and the modem data pump task 314 implement existing modem protocols for renegotiating the baud rate during a transfer sequence. Such renegotiation protocols are also employed if modem data errors are detected or if ambiguous data is received during a modem data transfer sequence.

The host audio driver 164 causes the DSP-OS dispatcher task 146 to create an audio DSP-OS task 252. The audio DSP-OS task 252 performs sound file record and playback functions through a DSP stereo audio codec driver 280. The DSP stereo audio codec driver 280 communicates through the audio interface circuit 68 to the stereo audio codec circuit 54. The DSP stereo audio codec driver 280 is interrupt driven according to interrupts generated by the stereo audio codec 54 through the audio I/F 68.

The audio DSP-OS task 252 functions as a server for the host audio driver 164. The audio DSP-OS task 252 performs the commands requested by the host audio driver 164 according to messages routed through the corresponding mailboxes.

During audio record operations, the DSP stereo audio codec driver 280 receives sound samples from the stereo audio codec circuit 54. The sound samples from the stereo audio codec circuit 54 comprise 16 bit integer data values. The DSP stereo audio codec driver 280 converts the sound samples into a sound data stream having the standard data format, and transfers the sound data stream to the audio DSP-OS task 252.

The DSP stereo audio codec driver 280 continuously requests data buffers from the audio DSP-OS task 252 while transferring the sound data stream to the audio DSP-OS task 252. The DSP stereo audio codec driver 280 writes a block of the sound data stream into each data buffer and then requests a new data buffer for the next sound data block. The audio DSP-OS task 252 may not receive sufficient DSP 61 processor time to process the data buffer requests from the DSP stereo audio codec driver 280 if higher priority DSP tasks cause an exhaustion of available MIPS on the DSP 61.

If the DSP stereo audio codec driver 280 does not receive a new buffer from the audio DSP-OS task 252 and loses incoming sound data, then the DSP stereo audio codec driver 280 logs a real-time error. Also, if the DSP stereo audio codec driver 280 detects that the last data buffer has not been processed by the audio DSP-OS task 252, then the DSP stereo audio codec driver 280 logs a real-time error. The DSP stereo audio codec driver 280 may log the real-time errors directly to the performance task 320. Alternatively, the DSP stereo audio codec driver 280 may report the real-time errors to the audio DSP-OS task 252 when queried by the audio DSP-OS task 252 for real-time errors. The audio DSP-OS task 252 then logs the reported real-time errors to the performance task 320 if real-time error logging for the audio DSP-OS task 252 is enabled.

The audio DSP-OS task 252 preprocesses the sound data stream through a compression driver 210 according to the requirements of the host application program 202. The preprocessed sound data stream is then transferred to the host audio application program 202 through the device independent I/O interface of the DSP host driver 130, and up through the host audio driver 164.

The compression driver 210 converts the sound data stream from the standard data format into a compressed data format. The PCM audio driver 214 converts the sound data stream from the standard data format into a PCM format for Waveform files.

During audio playback operations, the host audio application program 202 transfers a sound data stream to the host audio driver 164 through the audio application program interface 171. The host audio driver 164 transfers the sound data stream to the host DSP driver 122 through the DSP interface 120. The audio DSP-OS task 252 receives the sound data stream from the host DSP driver 122 through the compression driver 210 or the PCM audio driver 214 according to the requirements of the host application program 202.

The compression driver 210 converts the sound data stream from the compressed data format into the standard data format during audio playback. The PCM audio driver 214 converts the sound data stream from the PCM format for Waveform files into the standard data format during playback.

The audio DSP-OS task 252 then transfers the standard format sound data stream to the DSP stereo audio codec driver 280 through the device independent I/O interface. The DSP stereo audio codec driver 280 converts the sound data stream into the 16 bit integer data values required by the stereo audio codec circuit 54 and then transfers the decompressed 16 bit sound data values to the stereo audio codec circuit 54 to generate sound playback.

The DSP stereo audio codec driver 280 continuously requests data buffers containing the sound data stream from the audio DSP-OS task 252 while receiving the standard format sound data stream from the audio DSP-OS task 252. The audio DSP-OS task 252 may not receive sufficient DSP 61 processor time to pass the data buffers to the DSP stereo audio codec driver 280 if higher priority DSP tasks cause an exhaustion of available MIPS on the DSP 61. If the DSP stereo audio codec driver 280 does not receive a new buffer from the audio DSP-OS task 252 at the appropriate time required by the audio playback operation, then the DSP stereo audio codec driver 280 logs a real-time error. The DSP stereo audio codec driver 280 may log the real-time errors directly to the performance task 320. Alternatively, the DSP stereo audio codec driver 280 may report the real-time errors to the audio DSP-OS task 252 when queried by the audio DSP-OS task 252 for real-time errors. The audio DSP-OS task 252 then logs the reported real-time errors to the performance task 320 if real-time error logging for the audio DSP-OS task 252 is enabled.

For one embodiment, the host audio application program 202 transfers sound data values from Waveform sound files to the audio DSP-OS task 252 during audio playback operations. The Waveform sound samples conform to the Waveform application program interface provided by Microsoft.RTM. Corporation.

FIG. 9 illustrates another embodiment of the multifunction I/O subsystem 14 that includes the analog phone line interface circuit 60 and associated codec circuits 70 and 72, the stereo audio codec circuit 54, the phone interface circuit 66 and the audio interface circuit 68. A bus interface 45 enables access to the phone interface and audio interface circuits 66 and 68 over the host bus 44. In this embodiment, the DSP-OS drivers and tasks and associated software previously disclosed are executed by the host processor 32 and are referred to as input/output (I/O) drivers and tasks.

FIG. 10 illustrates the software architecture of the host processor 32 for the embodiment of the multifunction I/O subsystem 14 shown in FIG. 9 which includes host tasks and I/O tasks executed by the host processor 32. The application programs executed by the host processor 32 include the telephony application program 200 and the audio application program 202. The telephony application program 200 enables origination and reception of voice calls, data modem calls, and fax calls over the telephone line 22 and performs high-level user interface functions and telephony handshake functions.

The telephony application program 200 communicates with the phone control driver 160 and the fax-modem driver 166 through the telephony application program interface 170. The phone control driver 160 and the fax-modem driver 166 communicate with corresponding I/O tasks executed by the host processor 32 through the I/O interface 120 of the I/O driver 122. The telephony application program interface 170 provides telephony control services to the telephony application program 200. The audio application program 202 enables recording and playback of sound files. The audio application program 202 communicates with the audio driver 164 through the audio application program interface 171.

The I/O dispatcher task 146 processes requests from the phone control driver 160 and the audio driver 164 to create and delete I/O tasks. The I/O dispatcher task 146 also creates mailboxes for communications between the phone control driver 160 and the audio driver 164 and corresponding I/O tasks.

The performance task 320 provides performance monitoring services for I/O drivers and I/O tasks. The performance task 320 provides real-time error logging and real-time error reporting functions for the I/O drivers and I/O tasks that enable logging of real-time errors caused by exhaustion of available MIPS of the host processor 32. In addition, the I/O tasks optionally query the corresponding I/O drivers for real-time errors. Low priority I/O tasks can disable logging of the real-time errors reported by the corresponding I/O drivers to prevent selected low priority I/O tasks from causing dynamic MIPS scaling in a higher priority I/O task.

The performance task 320 determines a real-time error measure by smoothing the error logging information received from the I/O drivers. The I/O drivers log real-time errors by calling an error logging function of the performance task 320. Alternatively, the I/O drivers log real-time errors by incrementing a global error count variable that is monitored by the performance task 320.

The I/O tasks executing on the host processor 32 invoke calls to the performance task 320 to retrieve the real-time error measure. High priority I/O tasks use the real-time error measure to determine whether the available MIPS of the host processor 32 are being exhausted. A high priority I/O task can accordingly take steps to reduce MIPS consumption. In addition, the I/O dispatcher task 146 can prevent the launching of more I/O tasks if the real-time error measure is maintained above a predetermined level. The I/O dispatcher task 146 can also cause the operating system to notify the user of such conditions.

The phone control driver 160 and the fax-modem driver 166 cause the I/O dispatcher task 146 to create the modem tasks 310-314 which are I/O tasks executing on the host processor 32 that perform data modem transfers via the telephone line 22. The modem tasks 310-314 perform telephony functions through the telephony driver 282 executing on the host processor 32. The telephony driver 282 communicates through the phone interface circuit 66 to the analog phone line interface circuit 60 and the codec circuits 70 and 72. The telephony driver 282 is driven by interrupts generated by the phone interface circuit 66.

The data pump manager task 312 periodically executes a call to the performance task 320 to retrieve the real-time error measure. If the real-time error measure exceeds a predetermined threshold error count, then the data pump manager task 312 renegotiates the baud rate for the modem data transfer sequence underway. A reduced baud rate increases the available MIPS of the host processor 32 for the lower priority tasks. The data pump manager task 312 and the modem data pump task 314 implement existing modem protocols for renegotiating the baud rate during a transfer sequence.

The audio driver 164 causes the I/O dispatcher task 146 to create the audio task 252 which is an I/O task executing on the host processor 32 that performs sound file record and playback functions through the stereo audio codec driver 280. The stereo audio codec driver 280 communicates through the audio interface circuit 68 to the stereo audio codec circuit 54.

The audio task 252 functions as a server for the audio driver 164. The audio task 252 performs the commands requested by the audio driver 164 according to messages routed through the corresponding mailboxes. During audio record operations, the stereo audio codec driver 280 receives sound samples from the stereo audio codec circuit 54, converts the sound samples into a sound data stream having the standard data format, and transfers the sound data stream to the audio task 252.

The stereo audio codec driver 280 continuously requests data buffers from the audio task 252 while transferring the sound data stream to the audio task 252. The audio task 252 may not receive sufficient MIPS of the host processor 32 to process the data buffer requests from the stereo audio codec driver 280 if higher priority MIPS intensive tasks cause an exhaustion of available MIPS of the host processor 32.

If the stereo audio codec driver 280 does not receive a new buffer from the audio task 252 and loses incoming sound data, then the stereo audio codec driver 280 logs a real-time error. Also, if the stereo audio codec driver 280 detects that the last data buffer has not been processed by the audio task 252, then the stereo audio codec driver 280 logs a real-time error.

During audio playback operations, the audio application program 202 transfers a sound data stream to the audio driver 164 through the audio application program interface 171. The audio driver 164 transfers the sound data stream to the I/O driver 122 through the I/O interface 120. The stereo audio codec driver 280 continuously requests data buffers containing the sound data stream from the audio task 252. If the stereo audio codec driver 280 does not receive a new buffer from the audio task 252 at the appropriate time required by the audio playback operation, then the stereo audio codec driver 280 logs a real-time error. The audio task 252 then notifies the performance task 320 of the reported real-time errors if real-time error logging for the audio task 252 is enabled.

In the foregoing specification the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are accordingly to be regarded as illustrative rather than a restrictive sense.