OS/2 Multimedia Chapter – Architecture
by Maria Ingold
X.5 OS/2 MULTIMEDIA ARCHITECTURE
Originally known as Multimedia Presentation Manager/2 (MMPM/2), OS/2 multimedia has evolved from being a separate product from OS/2 2.0 to becoming a fully integrated part of OS/2 Warp. For the end user, OS/2 multimedia is a set of audio, image, and video applications. These applications can be used to record and play back audio files or digital audio from a CD, to view images downloaded from the internet or stored on a CD-ROM, or to watch and create movies on the PC. A multimedia developer can integrate multimedia functionality into an application, extend the existing multimedia capabilities, or create new function by using the application programming interface (API) layers provided by OS/2 multimedia.
The multimedia APIs are an extension of those provided by the OS/2 Presentation Manager (PM) architecture. Like PM, OS/2 multimedia provides both a messaging and procedural programming interface.
The OS/2 multimedia architecture is composed of three extensible layers. These are the Media Control Interface (MCI), the Stream Protocol Interface (SPI), and the Multimedia I/O (MMIO) Interface. These layers respectively provide an abstract view to the programmer of the underlying audio and video devices, a reliable method for transporting and synchronizing multimedia data streams, and independence from specific file, data, and storage formats. Figure X.2 illustrates the layout of the OS/2 multimedia system. Each layer includes a class of subsystem components and a manager to control the activities and interactions associated with these subsystems.
Figure X.2 OS/2 Multimedia System Architecture
X.5.1 OS/2 Multimedia Application and Overview
Figure X.2 also shows the relationship between the end user applications, and the underlying subsystems. Each application is both functional and exemplifies what can be accomplished using the OS/2 multimedia architecture.
As an example, each media player is a generic application that allows the user to play MIDI, digital wave audio, Autodesk FLI/FLC animations, and Ultimotion and Indeo videos. From the user’s perspective, he or she simply selects a file and then presses play on the media player. For example, a user may choose to play a wave file using the Digital Audio media player. The application opens the device type associated with the type of file (in this case the digital audio device type), loads the file, and cues it for playback. If a user wanted to play back a video, the player would open the digital video device and then load the file for playback.
The media player application sends calls such as play, rewind, and seek to the Media Control Interface. The Media Control Interface abstracts the underlying devices by representing them as logical media devices. The devices are controlled by the Media Device Manager (MDM). The digital audio device, for example, provides a generic interface to a variety of audio cards underneath via the wave audio driver. The wave audio driver is a Media Control Driver (MCD) that interprets a set of commands sent to it by the Media Device Manager such as open, play, stop, record, and pause and appropriately routes them through the subsystem. Adding additional MCDs extends the capabilities of the Media Control Interface. The driver can map to actual hardware, such as the wave audio driver maps to the audio card, or it can map to actions in software, such as in the playback of software motion video.
The Multimedia Data Converter allows the user to convert image files from one image format to another, and digital audio files between format types. The user can select a file mask to only view specific types of files, then he or she can select the files to be converted and the file format to which the files will be converted. This application uses calls to the Multimedia I/O subsystem to determine if the file is an audio or image file, it then gets the header of the file to be converted, sets the header of the output file, opens the source file, and writes the data out in the new format. This works as long as the file is a type supported by one of the OS/2 multimedia I/O procedures (IOProcs). The IOProc contains information about the file format, including its four character identification code. The Multimedia I/O architecture can be extended by adding additional I/O and CODEC procedures to the system.
The Stream Protocol Interface is rarely called directly by applications, but is instead made use of by the other subsystems. This layer provides the synchronization and streaming of data buffers from a source to a target device via stream handlers. Additional stream handlers can be added to extend the streaming capabilities of the system.
An example of the use of data streaming is when a user plays back a digital audio file as seen in Figure X.3. Figure X.3 shows how the stream handlers work with the other parts of the subsystem during the playback of an audio file. The Media Device Manager interprets the commands from the application to open the file and appropriate media drivers. The digital audio media driver uses a MMIO API to open the file. The media driver then constructs an audio stream protocol control block which it passes to the Stream Protocol Interface. This is how the media driver asks the SPI to load the file system and audio stream handlers.
Figure X.3 Digital Audio Playback
A stream is created to attach the audio stream handler to the audio device driver and the file system stream handler is attached to the MMIO file handle. The Stream Protocol Interface is then told to start the stream. During playback, the file system stream handler uses a MMIO API to read data from the file, and then places the data in the stream buffers as it becomes available. To maximize performance, the audio stream handler then transfers the buffers via interdevice driver communication at interrupt time. When the audio device driver consumes the last buffer (delineated by an end of file indicator), the stream handler informs the Syncronization/Streaming Manager (SSM), which informs the media driver, and ultimately the Media Device Manager which informs the application.
The next three sections go into detail about the Media Control Interface and its associated media drivers, the Stream Protocol Interface and its stream handlers, and the Multimedia I/O layer with its I/O and CODEC Procedures.