Visual Basic Expert SolutionsChapter 14Media Control InterfaceBy Dr. David Fullerton |
With the predominance of fast microprocessors, brilliant, high-resolution color displays, cheap RAM, CD-ROM drives, and sound cards, the multimedia industry is beginning to hit its stride in the mass market. More multimedia CD-ROM titles such as Microsoft's Encarta Encyclopedia and Broderbund's Living Books are arriving at local computer software dealers daily.
The technology of multimedia presentations is becoming as commonplace as color monitors, and many users have begun to expect to see flashy graphic displays demonstrating the usage of a particular function, or hear their computer explain why they can't press that button. The technology of multimedia is not just for flash, but is a truly useful application of today's newest computer hardware.
As a Visual Basic programmer, you can take advantage of these types of audio-visual presentations in your applications. Conveniently, Microsoft has included the Multimedia Control Interface custom control as an easy way to make use of multimedia commands through Visual Basic.
This chapter will discuss the following information about multimedia the Multimedia Control Interface (MCI):
Before learning about programming multimedia applications under Visual Basic in the next chapter, it is helpful to understand some of the hardware and software requirements for this environment. There are two groups of people that have different hardware and software requirements. Programmers like you have far greater hardware and software needs to develop multimedia applications than users who will just be playing back the multimedia files you have created.
Note: Most computer systems being sold today more than exceed the minimum for supporting multimedia. In fact, there are few non-multimedia systems sold. With Windows 95, these systems are becoming even more common.
For serious development of any multimedia programs, you will need the fastest PC with as much memory as you can afford. Multimedia tends to lean towards heavy processing requirements during the recording phase where real-time audio or video must be sampled, compressed, and saved as quickly as possible to maintain continuity.
Note: Don't skimp on the hardware if you are serious about multimedia development. The extra money you spend on hardware up front will save you many hours in the future. Unless you have too much time on your hands, the investment in better hardware will pay for itself.
Some guidelines on minimum hardware are as follows:
Again, these are minimum guidelines on hardware that will only get more intense as time goes on. (Assuming that they aren't obsolete by the time this is printed! 6x and 8x CD-ROM devices are now available.)
If you are planning on recording video, you will also need a video capture-board, such as Truevision's Targa+ 64 or Creative Lab's VideoBlaster. Again, if you are cheap with your hardware, the more likely that you will be disappointed with the results.
During development of your application, you should be viewing the results on something more representative of your user's hardware. The Multimedia PC Marketing Council suggests the following minimum requirements for multimedia "compliance."
By looking at these requirements, you've probably shaken your head and sighed since you haven't seen a 386sx PC with 2 Meg of RAM since you gave yours away to your mother-in-law. What really matters here is that you can test your system out on a "regular" user's system to see how it will look. Perhaps your minimum requirements will be higher than the listing above. If they are, make sure that your user's know that up-front. The last thing you want is to have an irate user call you because his 386sx isn't performing the way he expected.
Note: To be more realistic, the minimum should be the minimum
for an acceptable Windows 95 machine. That is a 496/33 with 8 meg and at
least a double speed CD-ROM. The 4 meg that Microsoft says is the minimum
yields unacceptable performance.
This section is only meant as a general guideline to prepare a multimedia developer for the costs involved in creating multimedia applications. There are many multimedia authoring packages available depending on the type and quality of the application that you want to build.
The best package for your development will require a little research. Browse through various trade magazines or on-line discussion groups to find out how other people rate the currently available authoring tools. Be aware of which version that a particular article or discussion is reviewing. Often times, the package that may have rated lowest on the charts in one review is highest on the charts in the next review due to the changes that were made between versions of the software. Use the guidelines in Table 14.1 to find the right package for your needs.
Table 14.1
Table 14.x Guidelines for Choosing Multimedia Authoring Tppls
Guideline | Commentary |
Don't use price as the only guideline. Look at the reviewer's comments for the features you'll use most. | You may find that the best package is not always the most expensive.
An article may discuss how poorly product performed overall while that same product performed the best in the features that you'll use most. |
Look for a commitment to a product line. | Larger companies will often phase out less profitable products after a short time, while smaller companies with a few core products may offer better long-term commitment to upgrades and feature enhancements. Also, smaller companies are more receptive to user suggestions for new features. |
Try out the software package. | When you finally choose an authoring tool, purchase it from a local vendor or mail-order outlet that will offer a money-back guarantee. This will insure that you can take back software that doesn't meet your needs. |
Note: Of course you already have a superior multimedia development tool in Visual Basic 4. Other tools may offer some advantages in certain areas. Visual Basic will offer you a strong interface for all aspects of multimedia development.
The Multimedia Control Interface (MCI) is a very powerful OLE Control that allows you to manipulate the recording or playing back of multimedia files on various MCI devices. Devices such as audio CDs, VideoDisc, and VCRs can be controlled by MCI. In addition, MCI can manipulate various file formats such as WAV files, AVI files, and MIDI files. While the MCI control can govern the operation of devices and files, it has no control over the data being played.
The basic format of the MCI control is that of a standard VCR. Standard controls include: Previous Track, Next Track, Play, Pause, Back, Step, Stop, Record, and Eject. Figure 14.1 shows the default MCI control buttons for the Visual Basic MCI custom control. Note that only the buttons that can be used are enabled.
Fig. 14.1 Default MCI Control buttons provide much of the functionality for multimedia devices.
Since many devices that can be managed through the MCI control, it is helpful to know the specifics about the devices before you begin coding. While many applications can be written to make use of the various devices, keep in mind that each manufacturer may or may not support the particular command set that you issue to the device. The following examples list the most popular devices that could be a part in a general user's system.
Since most PC manufacturer's have begun shipping CD-ROM drives as "standard equipment," it is possible that the CD drive will become as common on PCs as a hard drive. With the cost of CD-ROM drives dropping to the price of a floppy drive for a single-speed CD-ROM player, it is a good bet that those older PC's that don't currently have a CD-ROM drive will get one soon.
Most people with a multimedia compliant PC also desire to play audio CDs through their computer. The MCI control offers complete control over audio CDs through the default MCI control buttons.
Starting with Windows 3.1, all Windows systems had built-in multimedia support. The only problem you may face is support for older DOS-type programs that use the CD. Windows NT 3.51 and Windows 95 have full multimedia support built-in along with drivers for most devices. Under Windows 95 and Windows NT 3.51, support for CD-ROM uses the 32-bit CD-ROM File System (CDFS). MSCDEX.EXE is included as a last resort for products that use it directly.
Note: If you have an old operating system, the only prerequisite for using the audio CD functions is that the MSCDEX (Microsoft's CD Extensions) driver is loaded and the MCICDA.DRV file is in your Windows SYSTEM directory. These drivers make communication from the CD-ROM device driver to the Windows CD audio driver possible. They are also responsible for providing DOS with a drive letter for the CD-ROM drive. The MSCDEX.EXE file should have been installed by default with your DOS installation if you have MS-DOS version 5.0 or better. If you are using anything less than version 5.0, you should upgrade to the latest version of DOS or move to Windows 95. The MCICDA.DRV file is located on your Windows 3.1 installation diskette number 4 and is usually installed with the default installation.
Several animation or movie-type formats are supported by the MCI control. The Multimedia Movie format makes reference to the standard that Macromind Director established and that Microsoft adopted. It is based on the Macintosh format of Macromind Director files. Since most of the multimedia files that are available for Windows are not in the Multimedia Movie format, you may not need to utilize this format very often.
Many multimedia animation recordings are available in the AVI format, which stands for Audio-Video Interleaved. In this format, a frame of video is followed by a frame of audio. This way, when the segment is played back, even from a slow media such as a CD-ROM drive, the audio and video remain synchronized. The AVI format typically implements some form of compression to both reduce the file sizes and to improve the playback.
One of the most important details of using any animation or full-motion video segment is that of data storage. Since these multimedia files could be 5-10 megabytes for a short clip, you must be very conscious of any other processing that may be going on during the presentation. It is not wise to expect the user of your application to be able to have a full-motion video segment running smoothly while another process is composing three-dimensional ray-traced images in the background. Today's microprocessors are good, but your average user probably won't have that kind of "horsepower" to spare.
Since much of multimedia surrounds the ability to display full-motion video, this topic will be explained in greater detail later on in this chapter and will be demonstrated in Visual Basic code in Chapter 15, "Multimedia in Action".
One of the most common multimedia events that programmers want to take advantage of is the ability to play audio clips. Whether the audio clip is for informational purposes, error condition alerts, or just for fun, the MCI control can make the playback or recording of these files easy.
The Wave format, indicated by files that end in the WAV extension, is the de facto format of choice for Windows. Wave files not only contain the digital sampling information, but also include descriptive information about the format of this audio data. To illustrate, the wave format structure is shown in Listing 14.1
Listing 14.1 Format of a WAV File
As you can see, information about the number of channels and the sampling rate and depth is included in this structure. A wave file is called a RIFF (Resource Interchange File Format) file.
Most programmers would like to make their user-interface as slick as possible. They know that a good interface reduces support calls and provides a the user with a more intuitive application. To provide some of these functions, many developers have begun using more graphic images. Since image files, like most other forms of multimedia files, require large amounts of storage space, most developers are compressing images to save storage space. Refer to the section on image compression later on in this chapter for more information on saving space using graphic images. Also, Chapter 15, "Multimedia in Action," will go into greater hands-on detail on how to use graphic images in a user-interface.
Fig. 14.2 Flashy user-interfaces use graphic images to spice up the display.
Many other multimedia devices can be governed using the MCI control. The MCI control can handle devices of type AVIVideo, CDAudio, DAT, DigitalVideo, MMMovie, Scanner, Sequencer, VCR, Videodisc, or WaveAudio. If you are not running Windows 95 or Windows NT 3.51, you will need the proper DOS device driver and the corresponding Widows driver. (Check your user's manual for guidance on the installation of these drivers.) Devices such as VCRs, Video Disc Players, and MIDI instruments require special hardware. The Plug and Play technology incorporated in Windows 95 should greatly alleviate the problems with getting all those IRQs and DMAs correctly set.
Each technology has its own set of concepts that are identified with particular verbiage. Multimedia is no exception to this rule. The images and sounds that are encapsulated within a multimedia file need to be indexed for programmers to make better use of them. An audio CD contains many songs, but each title is labeled and indexed so that the choice of which song to play is up to the end user. The same is true for a video-cassette tape. The VCR can record multiple programs, but the counter is necessary to find each individual program.
These ideas can be applied to the indexing of the multimedia files through the MCI custom control. The concepts of tracks, time, sampling, and frames will be explained to provide a better understanding of the usage of these indices.
A track is a logical break in the media used to separate certain segments from other segments. In an audio CD, the tracks represent the particular songs on an album. In other media, tracks may have a completely different meaning, but will most likely be used in a similar way. An audio CD may be made up of 53 minutes of music, but the segment of music from 12 minutes 8 seconds to 17 minutes 22 seconds may contain a song that has a logical beginning and ending point. Therefore, it is assigned a track number.
A data CD may contain multiple "sessions" that contain data segments that were recorded together for a particular reason. For example, a roll of film is developed and then processed onto a CD during a session. This session would be seen as a track to the MCI custom control. Figure 14.3 illustrates the tracks on an audio CD being played by the CD player.
Fig. 14.3 CD tracks are logical subdivisions of data on the CD-ROM.
The concept of time indexing is not new. Just as a calendar is used to mark the passage of time in a global sense, we use our age to mark time in a more personal way. Programmers must make use of time to index the multimedia files for playback and recording.
Wave audio files and CD-ROMs use time as their own "personal" or local way. A wave audio file contains a segment of sound for a particular amount of time. The file's size may not accurately represent the amount of time that was recorded due to differing sampling rates or sampling depths. These will be explained more fully later in this chapter, however, these variables show that bytes alone may not be the most accurate way for measuring time in a wave audio file.
Since time is the indexing method that provides an accurate playback of a recorded segment, the next step is understanding the different time formats that the MCI custom control provides. Just as your age can be measured in years or in seconds since you were born, so the time slices used to index an audio file can be honed to provide the necessary accuracy. For example, a program that only needs to play a file of a recorded "ding" probably doesn't need to utilize the file's time in milliseconds. On the other hand, a file that contains over a hundred different sound effects that have been compiled into one file would need to know the exact start and finish times of any one of the effects to play them back properly.
The MCI control allows the programmer to access the time format of a specific recording. Time is stored as a 4-byte variable whose format represents measurement of time and frame rate from milliseconds to hours, depending on the needs for an application.
Note: Some devices do not recognize particular time formats since they do not make sense. A wave file contains no frames, therefore setting the time format to any of the frame-specific time formats will be ignored.
Sampling is the process of recording a sound signal and converting that analog signal into digital code. Sampling is a function of the following three parameters:
The sampling rate is the number of samples that are recorded during a particular time period. Often this value is expressed in samples per second. For example, if a wave audio file is recorded at 11.025kHz that means that 11,025 samples are taken each second to map the analog sound into a digital form.
The accuracy of this digital recording is affected by the number of
samples taken per second. The higher the sampling rate, the more accurate
the digital representation of the sound and the larger the file size. Figure
14.4 illustrates the recording parameters: Sample Rate, Channels,
and Sample. The combination of the three parameters is displayed
at the bottom.
Fig. 14.4 Audio sampling rates provide several levels of quality.
The digital recording accuracy not only depends on sampling rate, but it also relies heavily on sampling depth. For example, if a recording is being made with an eight bit sampling depth, the value for any particular sample could be one of 256 possible values. If however, the sampling depth was decreased to a two bit sample, the value could only be one of four possible values.
As the sampling rate or depth increases you will get better clarity, a more accurate digital recording, and a larger file. With a smaller sampling depth you will get a recording of poorer quality but a smaller file.
Additionally, the sampling depth could be expanded to multiple channels. A single-channel or mono recording is smaller than the same recording made with two channels or stereo. Depending on the application, the choice of sampling depths can produce widely variable file sizes. This point should be seriously considered when analyzing the application that will be recording or playing back wave audio files.
With video or animation sequences, similar quality and size issues arise when sampling rate is considered. Typical sampling rates for video and animation are 24, 25, and 30 frames per second. These speeds are fast enough for our brains to interpret them as "full-motion" images. Frames are merely a segment of time during which a sample is either recorded or played back. A frame-based time format allows the programmer to an index other than time or bytes to determine a position for playback or recording.
When recording or playing back, the sampling or frame rate is extremely important to the throughput of these images. The choice of 30 frames per second (fps) may overload a transport medium with data where a 24 fps animation would not. Each frame is dependent on the rate at which the data for that frame can be displayed or recorded. As with the wave audio files, video or animation files are heavily contingent on the color depth and frame dimensions to determine the amount of data that is being handled.
Since raw video frames can contain quite a lot of data, depending on the size and color depth, it is imperative to use some sort of compression scheme to reduce the amount of data that has to be stored. Most video file formats make provisions for compression, including the AVI format, and some are based on industry-standard algorithms that have be exclusively designed to compress full-motion video, such as the MPEG format.
Each format uses somewhat different compression techniques, however most techniques have a general compression style. The style makes reference to a "key" frame from which the next group of frames get their major characteristics. The frames following the key frame are made up of the changes that happen to that frame when compared to the key frame.
Figure 14.5 shows a sequence of frames which illustrate how frames are sequenced and how audio is aligned with the frames. This is using the AVIVIEW in the Video for Windows SDK.
Fig. 14.5 Key frame and changed frames allow a greater compression rate for video streams.
The key-frame technique is fairly good at compressing a series of frames that are similar, however, as time goes on the frames begin to differ more and more significantly from the key frame. This requires a new key frame to begin referencing new changes. The more often a key frame is registered, the better the quality of the following frames and the more storage space that is required for the video segment. The fewer the key frames, the better the compression, but the worse the quality. As you'll quickly find when working with video multimedia files, there are many trade-offs between quality, size, and speed.
When working with video compression, there are two methods to compress the video stream. Either you buy a video-compression board (hardware) for your system, which could run from several hundred to several thousand dollars, or you use an application's compression (software) to save the video stream into a compressed format. Each compression method has its particular strengths and weaknesses:
Image compression is very common and most users have probably had some sort of contact with the various compression methods. Whether by downloading an image from a bulletin board, or viewing an image off a CD-ROM encyclopedia, most have used a compressed image. But few programmers have a detailed understanding of the various image compression methods.
Image compression is usually separated between "lossy" and "lossless" methods. A lossless compression technique takes an image and reduces the size without compromising the integrity of the data. It does this by identifying repeating bytes and storing the byte and count of repeating bytes. Such compressions reduce the size of the file by up to about 60 percent. All of the data that was there before the image is compressed will be there when the image is decompressed for viewing later. A lossy compression technique removes small parts of the data to reduce the size of an image. Lossy compression makes an assumption that a given pixel is close to the other 16 pixels around it. Therefore, the redundant 15 pixels are eliminated. Now, since an AVI file is a sequence of DIBs, the remaining data is then compressed using lossless compression. This method does not produce the same image after it is decompressed. This type of compression usually has some parameter which allows the amount of data that is lost to be varied. The more data that is lost, the higher the compression and the less faithful the image will be to the original. With experience, the amount of data lost can be compromised with the image quality to obtain a compression/quality balance. Lossy compression often reduces the size of an AVI file by a factor of 10 or more. You can achieve some effects of lossy compression by reducing the sampling or using a slower frame. However, this does not introduce loss of image. This would simply reduce the number of images and, therefore, file size. You must experiment to ascertain acceptable sampling rates.
Table 14.2 describes the various common graphic image file formats and their corresponding compression techniques.
Table 14.2
Table 14.2 Graphic Image File Formats
Image
Format |
Compression
Type |
Comments
|
BMP | Lossless | Very common with Windows users, but compression is usually low. Run length encoding counts the duplicated pixels to reduce the file size. It is effective in some images with large single-colored areas, but not very effective on photographic images. |
PCX | Lossless | Common file format for some older images. Usually not of the preferred image formats for newer images. |
TIFF | Lossless | Common file format for high resolution images, and for images that are transferred between dissimilar operating systems. |
GIF | Lossless | Common file format that is limited to 256 colors. Popularized by Compuserve, image compression is good and images are transferable between dissimilar operating systems. |
TGA | Lossless | Used primarily for maintaining high-quality images with 24-bit color resolution. |
JPEG | Lossy | Provides excellent compression at the price of quality. Many bulletin board systems have begun using this image compression standard to allow users to download images with less on-line time. Compression of 30:1 is common. JPEG is also widely used on the internet to reduce file size. |
Fractal | Lossy | Provides superior compression at the price of speed. Compression times are long without special hardware and decompression times are much longer than most other methods. Uses a proprietary mathematical model for image compression that allows for image compression of 100:1. |
The standard Visual Basic picture property allows the loading of BMP, RLE, ICO, WMF, or DIB files. To use the other file formats in your Visual Basic application, you need to use the OLE container control or a third-party OLE Control or DLL. You can get a degree of animation with the PICCLIP custom control. If your application requires the storage of large quantities of graphic images, you may want to consider an alternative file format to reduce the storage requirements. Additionally, you may wish to store the images in a resource file and load the images only when the image is needed.
Since the MCI custom control can handle many different types of multimedia devices, a programmer needs to configure the control to perform according to the application.
The rest of this chapter will explain the details of the properties and commands to allow you to properly configure the MCI custom control.
The DeviceType property accepts values for the device that will be manipulated via the MCI custom control. The valid device types are as follows:
The structure for setting the DeviceType property is as follows:
[FormName.]MMcontrol.DeviceType [= DeviceName$]
DeviceName$ is a string variable with the value of one of the devices listed above.
Note: When giving syntax expressions, the following convention are used:
[]: Items in brackets are optional parts of the expression.
Bold: A required name, such as a property or method.
Italics: An object with a user-defined name.
$&!...: Indicate the datatype of the argument.
As mentioned earlier, the time format for each device depends upon the media type. Refer to Table 14.3 to choose an appropriate time format. All time is stored as a 4-byte integer where each byte represents one token in the format. Sometimes, not all bytes are used.
Table 14.3 Table 14.3 Time Formats for the MCI Control
Media Type | Time Format Setting | 4-Byte Position Value |
AVI, CD, MIDI, WAV | mciFormatMilliseconds | Milliseconds |
AVI, CD, MIDI | mciFormatHms | Hours, minutes, seconds |
CD | mciFormatMsf | Minutes, Seconds, Frames |
AVI | mciFormatFrames | Frames count |
MIDI | mciFormatSmpte24 | SMPTE 24-frame format |
MIDI | mciFormatSmpte25 | SMPTE 25-frame format |
MIDI | mciFormatSmpte30 | SMPTE 30-frame format |
MIDI | mciFormatSmpte30Drop | SMPTE 30-frame format using drop method |
WAV | mciFormatBytes | Byte count |
WAV | mciFormatSamples | Sample count |
CD | mciFormatTmsf | Tracks, minutes, seconds, frames |
Note: In this table, mciFormatSmpte24, mciFormatSmpte25, mciFormatSmpte30, and mciFormatSmpte30Drop all use the Society of Motion Picture and Television Engineers time format, which uses a 4-byte variable containing Hours, Minutes, Seconds, and Frames. Only the frame count changes between the various formats.
The syntax for the TimeFormat property is as follows:
[FormName.]MMControl.TimeFormat [= format&]
Note: Use the built-in intrinsic constants from Table 14.3 to specifiy format&.
The Position property can be used to read the current position of the media. This is useful as an indicator in a user-interface which displays statistics on the current file or track.
The Position property depends on the value that has been set in the TimeFormat property. If an application will have a display that makes use of the position property, try to choose a time format that will make sense for the type of media that you are using. While milliseconds is a valid time format for an Audio CD, it is not that useful to display a 7-digit value for a display. It is more useful to display minutes and seconds in this case. The Position property is read-only at runtime and not available at designtime.
The syntax for obtaining the Position property is as follows:
x& = [FormName.]MMControl.Position
The value of x will be a long integer that must be parsed to display the appropriate value. Use Table 14.3 as a guide to format the Position value for display.
The From and the To properties allow the media position for playback to be changed. Both properties require an additional command to be issued to function properly. Setting the From property not followed by a Play command will cause the From property to be ignored. In the same way, setting the To property not followed by a Play, Record, or Seek command will also be ignored.
The From and To properties consist of 4-byte values that correspond to the time format chosen for the device and media type. The To and From properties are not available at design. Use the following syntax to set the From and To properties at runtime:
[FormName.]MMControl.To [= timevalue&]
[FormName.]MMControl.From [= timevalue&]
timevalue is a 4-byte value using the current time format.
There are four properties that identify track information. All of these properties are read-only and available only at runtime.
To read the Tracks property, use the following syntax:
The Mode property provides a method of checking the current state of an MCI device. This is useful for providing error-handling and error-prevention by only allowing state-appropriate commands to be issued. Table 14.4 shows the various values that can be returned as an integer value from the Mode property.
Table 14.4
Table 14.4 Mode Property Values
MCI Device Mode | Value | Constant |
Device Not Open | 524 | mciModeNotOpen |
Device Open and Stopped | 525 | mciModeStop |
Device Open and Playing | 526 | mciModePlay |
Device Open and Recording | 527 | mciModeRecord |
Device Open and Seeking | 528 | mciModeSeek |
Device Open and Paused | 529 | mciModePause |
Device Open and Ready for Commands | 530 | mciModeReady |
The Command property provides a general means to control a MCI device via a command list. These commands are often used in conjunction with other MCI properties.
Table 14.5 lists the various commands that can be sent to an MCI device and their uses.
Table 14.5
Table 14.5 MCI Commands
Command | Command Usage |
Open | Opens the MCI device for use. If a device is currently open by another process, this will return an error. If the MCI device media is a file, the name is specified in the FileName property. |
Close | Closes the MCI device that is currently open. |
Play | Begins playing the selected MCI device's media from the current position. The starting position can be altered using the From and To properties. |
Pause | Suspends the current playback or recording operation of the MCI device media. If a device is already paused, this command will resume the playback or recording from the currently pause position. |
Stop | Stops the playback or recording of an MCI device's media. |
Back | Moves backwards in the media. This command is used in conjunction with the Frames property. |
Step | Moves forwards in the media. This command is used in conjunction with the Frames property. |
Prev | Moves to the beginning of the current track. If the Prev command is issued within three seconds of another Prev command, the operation moves backwards one track unless the media is at the first track. |
Next | Moves to the next track. If the current track is the last track, it will move to the beginning of the last track. |
Seek | Moves to the position indicated by the value of the To property. |
Record | Begins recording at the current position or at the position indicated by the From or To properties. |
Eject | Ejects media from the MCI device. |
Sound | Plays the sound indicated by the FileName property. |
Save | Saves the current recorded sound to the file indicated by the FileName property. |
To use the Command property, use the following syntax:
[FormName.]MMControl.Command [= commandstring$]
commandstring$ is one of the commands listed in Table 14.5.
The Notify property is typically used when the time-delay is significant during a particular event. For example, seeking on a CD-ROM is relatively quick compared to seeking on a VCR. Therefore, by setting the Notify property to True before a seek starts, the system can be used to perform other activities until the Done event indicates that the task has finished.
Use the following syntax to set the Notify property:
The Done event will be triggered upon completion of the activity.
The status of the MCI device can be refreshed by using this specialized timer event. Typically, this is used to update the user-interface with the track number, time, or frame number of the current MCI device's media.
Use the following syntax to set the UpdateInterval property:
time% is the number of milliseconds between StatusUpdate events. Setting the UpdateInterval value to 0 disables the StatusUpdate event.
There are times when you may want to do things beyond that allowed by the MCI Multimedia control provided with Visual Basic 4. As a Visual Basic programmer, you have full access to the multimedia API. However, there are certain cases in which you may have to move to C++. Those are cases where callbacks are used. In other instances, you may want to build an OLE interface to deal with the capability that you want to provide. For more information, see Chapter 20, "OLE Controls, Add-Ins, and 32-bit DLLs."
In addition to the properties available in Visual Basic's MCI custom control, several other commands that aren't directly accessible are very useful for programming multimedia applications. To use these commands, you will need to make calls to the dynamic linked library (DLL). For more information on using DLLs under Visual Basic, see Chapter 23, "Mixed-Language Development with DLLs". All references in this section will be 32-bit specific.
Note: Visual Basic 4 has two sources to find information about the Multimedia API calls. For the 16-bit environment, the API calls are stored in WINMMSYS.TXT. For the 32-bit operating systems, the Multimedia API is integrated with other Windows API calls in WIN32API.TXT. The API Text Viewer can be used to get specific information from these files.
You may wish to offer the user control over the audio channels from within your application. Since the Visual Basic custom control does not make provisions for this, the DLL must be referenced. The following commands relate specifically to reading the current volume level (waveOutGetVolume) and setting the volume level (waveOutSetVolume).
deviceID is the Windows identification to the audio device that plays back the waveform files and sounds and volumelevel is the 32-bit volume level (16-bits per channel) that is returned by the function. A value of 0x0000 (zero) means that the channel is set to its lowest level while a value of 0xFFFF (65536) means that the channel is at full volume.
The waveOutSetVolume command is similar to the waveOutGetVolume command in its structure, however instead of returning a value, it is used to pass the volume level to the device. The following code line will set the volume of device deviceID to the level specified in VolumeLevel:
Note: Not all devices support 16-bit volume definition per channel nor do all devices support stereo output. Those devices that do not support stereo output return the volume level in the low-order word. Devices that do not support 16-bit per channel volume will still return the 16-bit value that was set.
One of the most powerful and easy ways to make use of the multimedia control interface's capabilities is by passing command strings to the DLL. These command strings provide an additional way to control an MCI device without using MCI custom control properties.
One of the easier techniques is to use the mciExecute function. The prototype for this function is as follows
With this function you can simply execute any MCI command, such as the following:
or
or
The trick to this is the use of specific keywords and the system registry. cdaudio is a key word that MCI knows about. WAV is associated with Wave Sound in the registry. mciExecute requires that you know exact commands and strings to send to the MCI interface.
Sending a command string through the Multimedia Control Interface involves setting up a command line that can be interpreted by the MCI OLE.
These commands allow the programmer to utilize the multimedia functions without learning more difficult DLL calls. Additionally, debugging applications is much easier when you can read the codes that you are sending to the devices.
The mciExecute function is a variation of the mciSendCommand function that allows you to completely utilize the MCI API. The mciSendCommand function has the following prototype:
To use this function, you will need to fill in a set of structures with the information. Chapter 15, "Multimedia in Action," fully explores this concept. Following is the structure to pass for opening a device:
Since Visual Basic does not support callbacks, set the first parameter to vbNullChar. You will also need the API call mciGetDeviceID to get the parameter wDeviceID. lpstrDeviceType is the device type and lpstrElementName is the command you are sending. You can also give the name an alias in lpstrAlias.
Most of these parameters are set with a set of predefined constants. You can find all requisite values in the API text viewer for both 32-bit and 16-bit API calls. You simply copy the values along with structures and declarations into your program.
To have complete control over your multimedia environment, there are many other structures and parameters to master. Of course, most of the time mciExecute will more than adequately suit your needs. To see everything about the MCI, check out the Multimedia Programmers Guide in the Microsoft Windows SDK.
You have learned much of the terminology regarding multimedia and have learned many of the characteristics that make multimedia applications unique. You also saw many of the problems with multimedia and some of the techniques to get around these problems.
You also gained an understanding of the Multimedia Control Interface and the MDI custom control. To look at some of the other advanced techniques using Visual Basic, see the following chapters:
| Previous Chapter | Next Chapter | Search | Table of Contents | Book Home Page |
| Buy This Book | Que Home Page | Digital Bookshelf | Disclaimer |
To order books from QUE, call us at 800-716-0044 or 317-361-5400.
For comments or technical support for our books and software, select Talk to Us.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.