Abstract:
Presentation of digital video and audio data in a computer system. Am application program may call upon a driver program to manipulate streams of video and audio data, including commands to present the video or audio to an operator, retrieve status information about the presentation, simultaneously present graphics with video data, halt or pause presentations, allocate or release resources for presentation, and group multiple streams for synchrony. The driver program may operate upon the grouped streams in synchrony in response to unified commands from the application program. An interface to the driver program may comprise a interrupt instruction invoked with a designated interrupt and a designated set of commands: initialization; open and close; play, pause, stop, seek, and step; group; set and get; installation; and termination. The driver program may be called upon using a standardized interface for such functions, in which the application program may indicate a designated set of parameters for each function call.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates to a video and audio data presentation interface. 
     2. Description of Related Art 
     Known computer systems, particularly personal computer systems known as &#34;PC&#34;s, often have coupled peripheral devices that are able to perform some special function. For example, a peripheral device may be coupled to a computer system for presenting video or audio to an operator, such as by displaying pictures or producing sounds for the operator to view and hear. It is generally desirable to place these peripheral devices under the control of a central processing unit (CPU). Particularly, it is generally desirable to control the operation of these peripheral devices from an application program executing on the CPU. 
     One known method for controlling a peripheral device from an application program is use of a &#34;driver&#34; program. A driver program may be installed with an operating system for the CPU (it may be installed with installation of the operating system, or it may be added later), and may be responsive to a designated interrupt. The application program may execute the designated interrupt to cause the driver program to operate, and may pass arguments, such as control signals or data, to the driver program for its use. The driver program may then control the peripheral device directly. 
     While this method achieves the purpose of controlling the peripheral device, it has the drawback that two or more driver programs may attempt to use the same designated interrupt. This problem has sometimes been addressed by &#34;chaining&#34;, in which the operating system may first assign the interrupt to the driver program that was most recently installed. If this driver program does not recognize the function which the application calls on it to perform, it may cause the operating system to select the driver program that was next-most-recently installed. Chaining may be repeated until some driver program responds to the interrupt, or until an error is returned to the application program. 
     Chaining is subject to drawbacks. First, if the chain of driver programs that must be selected in turn is too long, response to the application program will be slow. This can be a particularly serious problem in the case of presentation of video and audio data. Slow response may cause the presentation to vary significantly from a realistic presentation. 
     Second, a chain of driver programs, each attempting to respond to the same designated interrupt, has been found to be prone to error. A relatively innocuous programming error in the operating system, or a relatively minor ambiguity in the arguments used to call upon the driver program, can cause the wrong driver program to be selected. When the wrong driver program is selected, results for the application program are generally unpredictable at best, and catastrophic at worst. 
     Accordingly, it would be desirable to use a limited number of designated interrupts while avoiding the drawbacks of chaining. 
     Another drawback of the prior art is related to presentation of video and audio data. Generally, a first peripheral device may be used for video display, while a second peripheral device may be used for audio presentation. Accordingly, different driver programs may be used to control the different devices. However, commonly an application program seeks to present video and audio in synchrony, and must thus attempt to coordinate its commands to different driver programs to achieve that result. 
     Although some known drivers provide commands for synchronizing data streams, the application program is still generally required to call upon the driver program for each data stream separately. This can increase the complexity of the application program, particularly where there are a multitude of commands to be issued to the driver program. For example, in presentation of video and audio data, there may be commands for &#34;FAST FORWARD&#34;, &#34;PLAY&#34;, &#34;PAUSE&#34;, &#34;REWIND&#34;, and &#34;STOP&#34;. It would be advantageous if a group of data streams that are to be synchronized could be treated by the application program as a single data stream, so that only a single command to the driver program would be required to manipulate the entire group. 
     Another drawback of the prior art is that application programs (or at least their programmers) are generally required to comprehend the nature of the peripheral device to make full use of the driver program&#39;s commands. For example, if the application program seeks to display both video data and graphics on a single display, it must generally comprise a fair amount of knowledge about how the peripheral device will respond to commands to do so. It would be advantageous if the driver program would handle this for the application program. This would simplify application programs and allow the driver program to use information about the nature of the video and audio peripheral devices, which would otherwise be easy for the application program to mistake. 
     Another drawback of the prior art is that application programs may desire to provide video or audio data for presentation, but this is not well supported by prior art. For example, the application program may generate the video or audio data itself, may generate the video or audio data in response to data it retrieves from a file, or may retrieve video or audio data from another device (such as a video camera, an MPEG capture device, or a communication device, such as one coupled to a modem or to a T1 communication line). Known interfaces for presentation of video and audio data do not provide operations to make such operation convenient. 
     Accordingly, it is an object of this invention to provide an improved method for presentation of video and audio data. 
     SUMMARY OF THE INVENTION 
     The invention provides an improved method for presentation of digital video and audio data in a computer system, in which the video or audio data may be generated by an application program or may be retrieved from a recorded medium. In a preferred embodiment, an application program may call upon a driver program to manipulate streams of video and audio data, including commands to (1) present the video or audio to an operator, (2) retrieve status information about the presentation, (3) simultaneously present graphics with video data, (4) halt or pause presentations, (5) allocate or release resources for presentation, and (6) group multiple streams for synchrony. The driver program may operate upon the grouped streams in synchrony in response to unified commands from the application program. 
     In a preferred embodiment, an interface to the driver program may comprise a interrupt instruction invoked with a designated interrupt and one or more of the following commands: 
     (1) an initialization command--to initialize the driver program; 
     (2) open and close commands--to open and close a data stream, respectively; 
     (3) play, pause, stop, seek, and step commands--to present a data stream, pause a presentation, stop a presentation, relocate to a designated position in a data stream, and step increment a data stream, respectively; 
     (4) a group command--to designate multiple streams as a group to be synchronized; 
     (5) set and get commands--to set and get parameters (of the driver or a data stream), respectively; 
     (6) installation commands, including a callback command and a signal command--to install a callback function or a signal for a data stream, respectively; and 
     (7) a termination command--to terminate and release resources for the driver program. 
     In a preferred embodiment, the driver program may be called upon using a standardized interface for such functions, in which video and audio data for presentation may be treated uniformly whether the data is generated by an application program or retrieved from a recorded medium. In the standard interface, the application program may indicate the following set of parameters for each function call: an identifier of which command is called upon, an indicator for which data stream is to be manipulated, a set of data flags, a data value or data pointer (which may be modified to comprise a returned data value or data pointer), and a register reserved for a returned error code. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 shows a block diagram of a computer system including a video data presentation device. 
     FIGS. 2A, 2B, 2C, and 2D (collectively called &#34;FIG. 2&#34;) show a flow diagram of an interface between an application program and a device for presenting video and audio data. 
     FIG. 3 shows a flow diagram of a responsive procedure for a device for presenting video and audio data. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT 
     Those skilled in the art would readily understand, after perusal of this application, that methods and techniques described for operation on a processor or computer system would be readily implemented on digital computer systems such as those described herein without undue experimentation. Accordingly, detailed description of computer programing techniques or methods of implementation are not set forth herein, except where such techniques or methods are specific to the invention. 
     Information in this application may be supplemented by a technical appendix, appearing at the end of this text. The technical appendix is an integral part of the disclosure of this application, and moreover is hereby incorporated by reference as if fully set forth herein. 
     SYSTEM INCLUDING PRESENTATION DEVICE 
     FIG. 1 shows a block diagram of a computer system including a video data presentation device. 
     A computer system 101 may comprise a processor 102, memory 103, and mass storage 104, all coupled to a system bus 105. For example, in a preferred embodiment, the computer system 101 may comprise an IBM compatible PC, having an Intel 386 processor operating at 25 MHz or better, with at least 2 MB of RAM and at least 2 MB of space free on a magnetic disk drive mass storage unit, and having an ISA or EISA bus. Such systems are known in the art. 
     The computer system 101 may also comprise a video and audio presentation device 106. In a preferred embodiment, the presentation device 106 may comprise a VGA display controller that supports a VESA feature connector, and a peripheral device such as the &#34;Reel Magic&#34; product (available from Sigma Designs Corporation, of Fremont, Calif.). The memory 103 may comprise an operating system 107, such as MS-DOS 6.2 or a variant thereof, and a driver program 108 as disclosed herein. The driver program 108 may sometimes be referred to herein as the &#34;FMP DOS&#34; driver. 
     In a preferred embodiment, the presentation device 106 may be coupled to the system bus 105 using a known methods for coupling an add-in board to the system bus 105, such as the ISA or EISA specification for a device to bus coupling. The processor 102 may communicate with the presentation device 106 by means of the bus 105, or by means of reading from and writing to the memory 103; communication techniques therefor are known in the art. 
     In a preferred embodiment, a data stream 109 comprising video or audio data for presentation, may be held in memory 103, in mass storage 104, or may be received by the computer system 101 from another peripheral device, such as a video camera or audio microphone, or from a communication medium, such as a network or telephone connection. Such other devices and communication media are known in the art. Such other devices may be coupled to the computer system 101 by means of the system bus 105, by means of a direct connection to memory 103, or by other known means. 
     In a preferred embodiment, the FMP DOS driver program 108 may have the following commands: 
     
         ______________________________________FMP.sub.-- INIT       initialize the driver program 108FMP.sub.-- OPEN       open a data stream 109FMP.sub.-- CLOSE       close a data stream 109FMP.sub.-- PLAY       present (&#34;play&#34;) a data stream 109FMP.sub.-- PAUSE       pause a data stream 109FMP.sub.-- STOP       stop a data stream 109FMP.sub.-- SEEK       locate (&#34;seek&#34;) a designated position in a       data stream 109FMP.sub.-- STEP       increment the position of a data stream 109       by one video frameFMP.sub.-- GROUP       designate data streams 109 as a groupFMP.sub.-- SET       set a parameter of the driver program 108       or a data stream 109FMP.sub.-- GET       get a parameter of the driver program 108       or a data stream 109FMP.sub.-- CALLBACK       install a callback function for a data stream       109FMP.sub.-- SIGNAL       install a signal for a data stream 109FMP.sub.-- UNLOAD       terminate the driver program 108 and       unload it from memory______________________________________ 
    
     These commands are described in more detail herein. 
     In a preferred embodiment, when an application program, stored in memory 103 or in mass storage 104 and controlling the processor 102, desires to use the capabilities of the presentation device 106, it may execute an interrupt instruction with a designated interrupt, and thus cause the processor 102 to generate an interrupt, as is known in the art. The interrupt may be responded to by the operating system 107, which may direct the interrupt to a driver program 108. 
     In a preferred embodiment, the operating system 107 may be responsive to a calling sequence used by the application program to command the driver program 108. In a preferred embodiment, the driver program 108 may comprise a unified calling sequence for each of its functions, so that all calls to the driver program 108 may be easily identified by the operating system 107. 
     As noted herein, in a preferred embodiment, the computer system 101 may comprise an Intel 386 processor 102; such a processor may comprise a set of 16-bit registers including AX, BX, CX, and DX registers. In a preferred embodiment, a unified calling sequence may comprise registers BX, CX, DX and AX, and may be as follows: 
     BH command identifier 
     BL identifier for data stream (sometimes called a &#34;stream handle&#34;) 
     The symbols BH and BL identify high and low halves of register BX. 
     CX data flags 
     DX (with AX) 32-bit data value or data pointer, with the high half in DX and the low half in AX 
     In a preferred embodiment, no registers other than BX, CX, DX and AX will be read by the FMP DOS driver program 108. 
     In a preferred embodiment, a unified return sequence may comprise registers BX, CX, DX and AX, and may be as follows: 
     BH error code, if any 
     BL DOS error code, if BH indicates a DOS error 
     DX (with AX) 32-bit return data value or data pointer, with the high half in DX and the low half in AX 
     In a preferred embodiment, no registers other than BX, CX, DX and AX will be modified by the FMP DOS driver program 108. 
     INTERFACE BETWEEN APPLICATION AND DRIVER PROGRAM 
     FIGS. 2A, 2B, 2C, and 2D (collectively &#34;FIG. 2&#34;) show a flow diagram of an interface between an application program and a device for presenting video and audio data. 
     At step 201, the application program may determine whether the driver program 108 is installed. If so, the process proceeds with step 202, where the application program issues a command to install the driver program 108. Thereafter, the process proceeds with step 203. 
     In a preferred embodiment, the driver program 108 may be loaded before the application program starts. The driver program may install itself by seizing an unused interrupt within the range 80h to FFh. The driver program 108 may then store a predetermined text string such as &#34;FMPDriver&#34; relative to a location pointed to by the interrupt vector. At an offset of +2, a Pascal-type string may be stored; at an offset of +3, a C-type string may be stored. Pascal-type and C-type strings are known in the art. 
     In step 201, to determine whether the driver program 108 is installed, the application program may search the list of interrupt vectors for the installed driver. 
     In step 202, to install the driver program 108, the application program may search for the location of the driver program 108 in a predetermined location. In a preferred embodiment, this predetermined location may be a DOS environment variable, &#34;FMPDriver&#34;, whose value has been preset to a pathname of a DOS executable file for the driver program 108, such as &#34;FMPDRV.EXE&#34;. Upon finding the driver program 108, the application program may start the driver program 108 and reexecute step 201 to determine if the driver program 108 was successfully installed. 
     At step 203, the application program may issue the FMP --  INIT command to initialize the driver program 108. This command may reset the presentation device 106 and set any variables in the driver program 108 to their default values. 
     At step 204, the application program may issue the FMP --  GET command to get information about the driver program 108, such as its name, version, and a set of state information about the presentation device 106. 
     At step 205, the application program may determine whether to install a &#34;callback&#34; function with the driver program 108. If so, the process proceeds with step 206, where the application program may issue the FMP --  CALLBACK command to install a callback function with the driver program 108. Thereafter, the process proceeds with step 207. 
     A callback function is a function within the application program that may be called by the driver program 108, to provide feedback information to the application program. For example, the driver program 108 may call the callback function to provide information on the state of an operation that the presentation device 106 is still working on. 
     In a preferred embodiment, the application program may define one callback function for each data stream 109. If a data stream 109 has no callback function defined for it, a default callback function provided by the driver program 108 may be called instead (if one exists). In step 206, the application program may call the FMP --  CALLBACK function with a value for a data stream 109 that is a null indicator to specify the default callback function as the callback function to use. 
     In a preferred embodiment, the specified callback function may be called with a calling sequence that is standard for the language that function is written in, e.g., a Pascal standard calling sequence or a C standard calling sequence. Pascal standard calling sequences and C standard calling sequences are known in the art. Arguments may be passed in registers or on a calling stack, as is known in the art. 
     When arguments are passed in registers, the following calling sequence may be used: 
     BH message identifier 
     BL identifier for data stream (sometimes called a &#34;stream handle&#34;) 
     DX (with AX) 32-bit data value or data pointer, with the high half in DX and the low half in AX 
     Register DX (with AX) are referred to as the &#34;value&#34;. In a preferred embodiment, a zero value may be returned if the operation was a success. 
     In a preferred embodiment, one of the following messages may be passed to the callback function: 
     
         __________________________________________________________________________FMPM.sub.-- ERROR        An error occurred while executing a command        given by the application program. The value        may comprise an error code, which may com-        prise one of the following error codes: FMPE.sub.-- DOS        A DOS error occurred while reading the data        stream 109. Register AL may comprise the        DOS error code. FMPE.sub.-- HARDWARE        A hardware error occurred with the presenta-        tion device 106. Register AL may comprise        information about the error. FMPE.sub.-- STREAM        The data stream 109 comprises invalid data. FMPE.sub.-- DATA        The data stream 109 has no available data.FMPM.sub.-- SIGNAL        This message is issued when the data stream        109 reaches a position specified with the        FMP.sub.-- SIGNAL command, or when a period has        completed. The value may comprise the cur-        rent position of the data stream 109.FMPM.sub.-- COMPLETE        This message is issued when a command issued        by the application program has been com-        pleted, for example when a &#34;play&#34; command has        ended. The data stream 109 will be in a        ready mode, i.e., paused or stopped. The        value may comprise the command identifier for        the completed command.FMPM.sub.-- CANCEL        This message is issued when a new command has        been sent by the application program before        the previous command was completed. The        value may comprise the command identifier for        the canceled command.FMPF.sub.-- BUF.sub.-- CREATE        This message is sent when a buffered data        stream 109 is opened. The application pro-        gram may allocate and initialize buffers upon        receiving this message. The value may com-        prise the value passed by the application        program to the FMP.sub.-- OPEN command, and a zero        value may be returned on success.FMPF.sub.-- BUF.sub.-- CLOSE        This message is sent when a buffered data        stream 109 is to be closed. The application        program may release any memory allocated for        the buffer when this message is received.FMPF.sub.-- BUF.sub.-- SEEK        This message is sent to the application pro-        gram to seek to a given position in bytes.        The value may comprise the position to reach,        in bytes.FMPM.sub.-- BUF.sub.-- EMPTY        This message is sent to the application pro-        gram when the buffer for a buffered data        stream 109 is empty and more data is needed        to complete the command issued by the appli-        cation program. The application program may        specify an address for a new buffer with the        FMP.sub.-- SET -- FMPI.sub.-- BUF.sub.-- ADDR command.        Alterna-        tively, the application may set FMPI.sub.-- BUF.sub.-- LOOP        to cause the driver program to scan the same        buffer again. Otherwise, the data stream 109        will be stopped.FMPM.sub.-- BUF.sub.-- POS        This message is sent to the application pro-        gram when the buffer for a buffered data        stream 109 reaches a position indicated when        the data stream 109 was initiated (using the        FMPI.sub.-- BUF.sub.-- POS parameter). When the data        stream 109 is played, the application program        will generally receive this message before it        receives FMPM.sub.-- BUF.sub.-- EMPTY, so it does not have        to prepare the first buffer before opening        the data stream 109.__________________________________________________________________________ 
    
     At step 207, the application program may determine whether to set parameters for the presentation device 106 or the driver program 108. If so, the process continues with step 208, where the application program may issue the FMP --  SET command to the driver program 108. Thereafter, the process continues with step 209. 
     In step 208, the application program may issue the FMP --  SET command to prepare the presentation device 106 or the driver program 108 for the particular types of data stream 109 that the application program will seek to present. 
     At step 209, the application program may determine whether to open a new data stream 109. If not, the process repeats step 209 until the determination is YES. Thereafter, the process proceeds with step 211. 
     In step 209, the application program effectively loops until it seeks to open a new data stream 109, for example, its first data stream 109. In a preferred embodiment, there are two elementary types of data stream 109, those comprising only video data and those comprising only audio data. There are also more complex data streams 109; one such is an interleaved data stream 109, which may comprise both video data and audio data interleaved together. 
     When an application program opens an interleaved data stream 109, the driver program 108 may generate a group data stream 109, comprising the individual video and audio component data streams 109, grouped together for synchronization. Thus, when the application program seeks to present the group data stream 109, the video and audio component data streams 109 will be presented together in synchrony. 
     At step 211, the application program may open a data stream 109 by issuing the FMP --  OPEN command. 
     At step 212, the application program may determine whether to open another data stream 109. If so, the process may continue with step 211. 
     The application program may loop over steps 211 and 212 until it has opened all the data streams 109 it seeks to open. 
     In a preferred embodiment, the driver program 108 may open up to 255 data streams 109, each of which may have its own characteristics. These characteristics may comprise speed (i.e., speed of presentation), window size (i.e., the size of the video image for presentation), volume (i.e., the volume of sound presentation, time format (i.e., the number of frames per second). In a preferred embodiment, characteristics of a data stream 109 may vary depending upon whether it is a video or an audio data stream. 
     At step 213, the application program may determine whether to form a group data stream 109. If so, the process continues with step 214, where the application program may issue the FMP --  OPEN command to open a new group data stream 109, and may proceed thereafter to step 212. Otherwise, the process continues with step 215. 
     In a preferred embodiment, a group data stream 109 may comprise more than one elementary data stream 109. As with other data streams 109, the application program may issue commands with regard to a group data stream 109, such as to play, to stop, to step forward, to seek the data stream 109 to a designated location. Commands issued with regard to a group data stream 109 may apply to each of the elementary data streams 109 it comprises. 
     An application program may also select and deselect data streams 109 within a group data stream 109; it may thus designate which data streams 109 within the group data stream 109 should be affected by a command. This may be useful, for example, when a group data stream 109 comprises several tracks of audio data streams 109. The application program may thus select which of the several audio tracks to play. 
     At step 215, the application program determines whether to make a change to a group data stream 109. The process continues with step 214, where the application program may issue the FMP --  GROUP command to add, remove, select, or deselect a data stream 109 from the group data stream 109, and may proceed thereafter to step 215 again. Thereafter, the process proceeds with step 217. 
     The application program may loop over steps 215 and 216 until it has made all the changes to the group data stream 109 it seeks to make. 
     At step 217, the application program may determine whether to install a callback function for any of the data streams 109 or group data streams 109 it has opened. If so, the process proceeds to step 218, where the application program may issue the FMP --  CALLBACK command, in similar manner as in step 206, and may proceed thereafter to step 217 again. Thereafter, the process proceeds with step 219. 
     The application program may loop over steps 217 and 218 until it has installed all the callback functions it seeks to install. 
     At step 219, the application program may determine whether to set parameters for any data streams 109. If so, the process proceeds to step 220, where the application program may issue the FMP --  SET command to set parameters, and may proceed thereafter to step 219 again. Thereafter, the process proceeds with step 222. 
     At step 222, the application program may determine whether to install a new signal for a data stream 109 or to modify an existing signal for a data stream 109. If so, the process proceeds with step 223, where the application program may issue the FMP --  SIGNAL command to install a new signal or to modify an existing signal, and may proceed thereafter with step 222 again. Thereafter, the process proceeds with step 224. 
     The application program may loop over steps 222 and 223 until it has installed all the signals it seeks to install. 
     In a preferred embodiment, a signal may be a mechanism to inform the application program when a designated location in a data stream 109 has been reached by the presentation device 106. If that location is reached and the application program has installed a signal for a data stream 109, the driver program 108 will call the installed callback function for that data stream 109 with the message FMPM --  SIGNAL. The application program may receive this message and use the information to perform a designated procedure, to issue other commands, or to call upon the operating system 107 to trigger other system events. In a preferred embodiment, each data stream 109 may have only one signal outstanding at a time. 
     At step 224, the application program may determine whether to present (also called &#34;play&#34;) a data stream 109. If so, the process proceeds with step 225, where the application program may issue the FMP --  PLAY command to cause the presentation device 106 and the driver program 108 to present the data stream 109, and may proceed thereafter with step 224 again. Thereafter, the process proceeds with step 226. 
     At step 226, the application program may determine whether to step a data stream 109 forward. If so, the process proceeds with step 227, where the application program may issue the FMP --  STEP command to cause the presentation device 106 and the driver program 108 to step the data stream 109 forward one frame, and may proceed thereafter with step 226 again. Thereafter, the process proceeds with step 228. 
     At step 228, the application program may determine whether to seek a designated location within a data stream 109. If so, the process proceeds with step 229, where the application program may issue the FMP --  SEEK command to cause the presentation device 106 and the driver program 108 to seek a designated location in the data stream 109, and may proceed thereafter with step 228 again. Thereafter, the process proceeds with step 230. 
     At step 230, the application program may determine whether to stop a data stream 109. If so, the process proceeds with step 231, where the application program may issue the FMP --  STOP command to cause the presentation device 106 and the driver program 108 to stop the data stream 109, and may proceed thereafter with step 230 again. Thereafter, the process proceeds with step 232. 
     At step 232, the application program may determine whether to pause a data stream 109. If so, the process proceeds with step 233, where the application program may issue the FMP --  PAUSE command to cause the presentation device 106 and the driver program 108 to pause the data stream 109, and may proceed thereafter with step 232 again. Thereafter, the process proceeds with step 235. 
     In a preferred embodiment, a data stream 109 may comprise one of a set of &#34;play modes&#34;, each of which may designate a status of the data stream 109. These play modes may be as follows: 
     
         ______________________________________STOP mode  The data stream 109 is stopped. There is no      video picture and no audio sound.PAUSE mode The data stream 109 is paused. For an audio      data stream 109, this is the same as STOP      mode. For a video data stream 109, the last      (most recent) video frame is held frozen in a      presentation frame window.PLAY mode  The data stream 109 is playing, i.e., being      presented by the presentation device 106.      This mode is valid for both video and audio.SEEK mode  The data stream 109 is moving to a designated      location. This mode is valid for both video      and audio.STEP mode  The data stream 109 is moving forward one      frame. This mode is valid for video data      streams 109 only.______________________________________ 
    
     The PAUSE mode and the STOP mode may be termed &#34;ready&#34; modes. In a preferred embodiment, if the application program issues a command and the data stream 109 is not in a ready mode, the command is canceled and the application program callback function is called with the FMPM --  CANCEL message. 
     In a preferred embodiment, when the application program issues a command to enter PLAY mode, SEEK mode, or STEP mode, it may also designate the mode to enter when that command is completed. The application program may designate PAUSE mode, STOP mode, or the previous ready mode (i.e., the ready mode the data stream 109 was in before the new command). 
     In a preferred embodiment, the driver program 108 will cause control to return to the application program as soon as possible. Control may thus be returned before the command is completed. The application program may obtain the current mode for the data stream 109 by issuing the FMP --  GET command and waiting for the command to complete. When the command is completed, the driver program 108 will call the callback function for the data stream 109 with the FMPM --  COMPLETE message. 
     It may occur that a first data stream is in PLAY mode (i.e., it is being presented by the presentation device 106), and the application program seeks to present a second, different, data stream 109. In a preferred embodiment, if the presentation device is unable to present both data streams 109 at once, the FMP --  PLAY command for the second data stream 109 is given priority. The first data stream 109 will have its PLAY mode canceled, and it will be returned to the mode it would normally have if its PLAY mode has completed normally, and the callback function for the first data stream 109 will be called with the FMPM --  CANCEL message. 
     At step 235, the application program may determine whether to close a data stream 109. If so, the process proceeds with step 236, where the application program may issue the FMP --  CLOSE command to close the data stream 109, and may proceed thereafter with step 235 again. Thereafter, the process proceeds with step 237. 
     At step 237, the application program may determine whether to exit. If not, the process proceeds with step 212 (label D). Otherwise, the process proceeds with step 238. 
     At step 238, the application program may determine whether all data streams are closed. If not, the process proceeds with step 239, where the application program may issue the FMP --  INIT command to close all open data streams 109 and reset the presentation device 106. Thereafter, the process proceeds with step 240. 
     At step 240, the application program may determine whether it installed the driver program 108. If so, the process proceeds with step 241, where the application program may issue the FMP --  UNLOAD command to deinstall the driver program 108. Thereafter, the process proceeds with step 243, where it is complete and the application program may exit. 
     DRIVER PROGRAM FUNCTIONS 
     FIG. 3 shows a flow diagram of a responsive procedure for a device for presenting video and audio data. 
     In a preferred embodiment, an application program may issue a command to the driver program 108 to cause it to perform one of a set of functions. As noted herein, issue of that command may use a designated interrupt and a designated calling sequence. In a preferred embodiment, the driver program 108 may proceed as follows: 
     At step 302, the driver program 108 may run function associated with the command issued by the application program. 
     At step 303, the driver program 108 may determine whether the function caused an error. If so, the process proceeds with step 304, where the driver program 108 may run an error handler program. Thereafter the process proceeds with step 305, where it is complete and the driver program 108 may exit. 
     For each command, the application program may specify a flag FMPF --  TEST. This flag instructs the driver program 108 to return a value specifying whether the driver program 108 and the presentation device 106 supports that command, but to abstain from making any &#34;real&#34; changes. 
     The following pages A8--A24 describe commands that may be implemented in a preferred embodiment of the driver program 108. 
     ALTERNATIVE EMBODIMENTS 
     While preferred embodiments are disclosed herein, many variations are possible which remain within the concept and scope of the invention, and these variations would become clear to one of ordinary skill in the art after perusal of the specification, drawings and claims herein.