The MCI (Media Control Interface) is the
Windows API that gives programmer a high-level control on all
multimedia devices and resource files. MCI provides applications
with device-independent capabilities for controlling audio, video
and visual peripherals. This API has two different interface
levels: at the lower level (command-message interface)
the programmer controls devices by calling the mciSendCommand()
function. This function requires as its arguments the command to
be sent and some other command-specific parameters. The higher
level (command-string interface) is essentially a
textual version of the first, meaning that each command is
passed, together with its possible arguments, as a text string to
the mciSendString() function. As you can easily
imagine, the higher level offers a more friendly interface,
keeping programmers away from flags and structures. Even if MCI
is quite simple to use, I think that it should be a good thing if
it was object-oriented, too.
In this article, I'll try to explain how to build a simple
CD-audio player, using my CCdAudio class. This
class encapsulates the MCI command-message interface for
CD-audio. I hope it can be a good starting point to write
analogous classes for other multimedia devices: waveform-audio
devices, MIDI sequencers, etc. Building the player, however,
involves many other interesting issues. In particular, I'll show
Writing a set of classes to encapsulate the whole
MCI interface isn't so simple as you can think. The main
difficulty arises from the fact that it hasn't been thought in an
object-oriented way. The best thing is to start writing a base
class that implement a generic MCI device: this will be the base
class for all the other specific devices (Fig. 1).
CMciDevice overview
I called this base class CMciDevice. Its SendCommand()
protected member function hides the mciSendCommand() function,
but has also the capability to handle possible errors: when the
device is in the 'error report' mode, MCI errors are
automatically displayed using the MessageBox() function. You can
turn the error report on or off with the ReportErrors()
member function (the default is no error report).
In the CMciDevice class, as well as in CCdAudio, many of the
functions that implements MCI commands return a DWORD value that
is zero in case of success and a nonzero error code otherwise .
You can use this value to perform your own error handling (if you
want to know more about MCI error codes you can take a look at
the documentation). Other functions, however, don't return any
error code. In these cases, you can use the GetLastError()
function to get the code of the last occurred error.
The GetDevCaps()
function 'queries' the device to know if it has specific
capabilities (see the table below).
The GetdevcapsCompound
capability deserves some more explanation. MCI devices are
divided in two categories: simple and compound
devices. The difference is that a compound device needs a media
file to work. Cd-audio is a typical simple device, while
wave-recorder is a compound device since it needs a file (the
waveform) to work. For more details on CMciDevice you can go to
the reference guide
below.
MCI supports both the synchronous and asynchronous operating
mode. When a MCI operation is performed synchronously the mciSendCommand()
function returns only when its task has been carried out. In the
asynchronous mode, instead, the function returns immediately but
a 'callback' window has to be designated by passing its handle as
a parameter. When the required operation has been performed (with
or without success), MCI notifies the callback window of the
event sending it a MM_MCINOTIFY message. This
message has a parameter whose values can be used to understand if
the required operation has been successfully performed, aborted
or failed (see the sample project code for details about how to
do this). Asynchronous method is very convenient for long
operations that might require much time to be completed such as
playback or seek. This is the reason why, in CCdAudio, Play() and Seek() are
asynchronous by default.
When you open the CD drawer or when you insert a new CD and
close it, Windows sends applications a special
"plug-and-play" message: WM_DEVICECHANGE.
This message notifies an application or device driver of a change
to the hardware configuration of a device or the computer. Its
parameters are:
Event = (UINT) wParam;
dwData = (DWORD) lParam;
The opening of the CD drawer is signalled by the operating
system as a DBT_DEVICEREMOVECOMPLETE event. Its closing, instead,
is a DBT_DEVICEARRIVAL event. The dwData parameter points to an
event-specific structure, but DEV_BROADCAST_HDR is a structure
header common to all the structure types that dwData can point.
The dbch_devicetype field distinguishes ports from logical
devices: if it is equal to DBT_DEVTYP_VOLUME then dwData points
to a DEV_BROADCAST_VOLUME structure. In this structure, the
dbcv_flags field shows if the involved drive is a network drive
or a physical device. To verify if it is really a CD we have to
use the dbcv_unitmask field: it is an unsigned long value with a
set bit for each drive that caused the event: the first
(leftmost) bit for A, the second for B, and so on. For instance,
if the CD drive is D: its value will be 8 (= 0...01000) since D
is the fourth letter. Once we have obtained the drive letter,
reading the volume label and verifying if it is really a CD drive
is quite simple. Sample code follows:
BOOL CMCISampleDlg::OnDeviceChange( UINT nEventType, DWORD dwData ) {
DEV_BROADCAST_HDR *pdbch = (DEV_BROADCAST_HDR *) dwData;
switch(nEventType) {
case DBT_DEVICEARRIVAL: // CD drawer was closedif (pdbch->dbch_devicetype == DBT_DEVTYP_VOLUME) {
PDEV_BROADCAST_VOLUME pdbcv =
(PDEV_BROADCAST_VOLUME) dwData;
if (pdbcv->dbcv_flags == DBTF_MEDIA)
{
TCHAR szDrive[4];
// pdbcv->unitmask contains the drive bitsfor (UINT i=0; !(pdbcv->dbcv_unitmask & (1<<i)); i++);
wsprintf(szDrive, _T("%c:\\"), 'A'+i);
if (GetDriveType(szDrive) == DRIVE_CDROM) {
UpdateControls();
}
}
else {
// It is a network drive
}
break;
}
case DBT_DEVICEREMOVECOMPLETE: // CD drawer was openedbreak;
}
return TRUE;
}
Several MCI commands involve setting or getting a time. For
instance, the Play()
function requires two times: the time at which to start the
playback and the time at which to stop it. Both are DWORDs but,
however, MCI can interpret them in different ways, depending on
which time format has been previously set with the MCI_SET
command (or, in he CCdAudio class, with the SetTimeFormat()
member function). The allowable time formats for CD-audio are
milliseconds, MSF and TMSF. MSF stands for Minutes/Second/Frame
while TMSF stands for Track/Minute/Second/Frame. MSF and TMSF
times are packed in a single DWORD and special macros are used to
pack/unpack them. To simplify programmer's life, I wrote two
classes (CMsf and CTmsf ) for these time formats to eliminate the
necessity of remembering (and using) these macros. Both have an
overloaded operator DWORD to allow their use with those functions
that require DWORD parameters. Here are the two classes as they
are defined in the 'Mci.h' file:
To use CCdAudio you have to copy the 'Mci.h', 'Mci.cpp',
'CdAudio.cpp', and 'CdAudio.h' files in your project folder. Once
you have copied these files, include 'Mci.cpp' and 'CdAudio.cpp'
in your project. #include the CdAudio.h file at the beginning of
the module that needs it. Be aware that you have to link your
program with the 'winmm.lib' static library, or an error will
occur at link-time.
Using any MCI device requires the following steps:
Some bug fix in the CMciSendCommand
function: in the precedent version the error report
doesn't work fine. Now it works well also with the
CloseaAll() static function.
The constant InfoProduct was added in
CCdAudio
Author's note
This is a work in progress: I 'm continuously working to
improve it. I'll be grateful to you if you mail me your comments,
advice, or bug apparition reports!.
Last updated: 4 June 1998
Tools:
Add www.codeguru.com to your favorites Add www.codeguru.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.xReceive news via our XML/RSS feed
RATE THIS ARTICLE:
Excellent Very Good Average Below Average Poor
(You must be signed in to rank an article. Not a member? Click here to register)
All
Writing a set of classes to encapsulate the whole
MCI interface isn't so simple as you can think. The main
difficulty arises from the fact that it hasn't been thought in an
object-oriented way. The best thing is to start writing a base
class that implement a generic MCI device: this will be the base
class for all the other specific devices (Fig. 1). 
IE 7
Firefox 2.0
