home *** CD-ROM | disk | FTP | other *** search
/ CICA 1993 August / CICA.cdr / win_nt / multimed / technote / mmaware.zrt / MMAWARE.TXT
Encoding:
Text File  |  1992-03-27  |  14.1 KB  |  288 lines
  1. Microsoft Multimedia Technical Notes: Multimedia Aware Applications
  2. Page 1
  3.  
  4.                                    
  5.                                    
  6.                               Multimedia
  7.                                    
  8.                             Technical Note
  9.                                    
  10.                                    
  11.                                    
  12.                                    
  13.                                    
  14.                                    
  15.                                    
  16.                                    
  17.                                    
  18.                                    
  19.                    Creating Multimedia Applications
  20.                                Covering
  21.                    Multimedia Aware Applications and
  22.                     General Application Techniques
  23.                                    
  24.                                    
  25.                                    
  26.                                    
  27.  
  28.  
  29.  
  30.  
  31.                      Multimedia Developer Support
  32.                            One Microsoft Way
  33.                      Redmond, WA 98052-6399 U.S.A.
  34.                                    
  35.                           03/92 Revision 1.30
  36.  
  37.  
  38. Information in this document is subject to change without notice and
  39. does not represent a commitment on the part of Microsoft Corporation.
  40. The software described in this document is furnished under license
  41. agreement or nondisclosure agreement.  The software may be used or
  42. copied only in the accordance with the terms of the agreement.  It is
  43. against the law to copy the software on any medium except as
  44. specifically allowed in the license or nondisclosure agreement.
  45.  
  46. No part of this document may be reproduced or transmitted in any form
  47. or by any means, electronic or mechanical, including photocopying and
  48. recording, for any purpose without the express written permission of
  49. Microsoft Corporation.
  50.  
  51. This technical note is for informational purposes only.  MICROSOFT
  52. MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, IN THIS TECHNICAL NOTE.
  53.  
  54. Microsoft, MS-DOS, XENIX and the Microsoft logo are registered
  55. trademarks and Windows is a trademark of Microsoft Corporation.  Other
  56. trade names mentioned herein are trademarks of their respective
  57. manufacturers.
  58.                                    
  59.      Copyright 1992, Microsoft Corporation.  All Rights Reserved.
  60.                            Table of Contents
  61. Overview                                                 2
  62.      Current Version                                     2
  63.      Intended Audience                                   2
  64.      Questions?                                          2
  65. Classes of Applications                                  3
  66.      Multimedia Dependent Applications.                  3
  67.      Multimedia Aware Applications.                      3
  68. Different Levels of Awareness.                           3
  69. General Programming Guidelines                           4
  70.      Coping with Resource Availability.                  4
  71.      Yielding Resources to Other Applications.           4
  72.      Multimedia APIs Do Not Imply Multimedia Features    4
  73.      Don't Assume Number of Drivers to be Constant       5
  74.                                    
  75.                                Overview
  76.  
  77. This tech note details how to design and optimize an application using
  78. the Multimedia APIs in Windows.  It is meant for a developer working in
  79. C or a high-level language.
  80.  
  81. This note covers three main areas of creating multimedia applications:
  82.     applications which work with or without the Multimedia API
  83.      extensions to Windows
  84.     coping with unavailable resources
  85.     yielding resources to other applications.
  86.  
  87. Current Version
  88. The current version of this document can be obtained from the Microsoft
  89. Multimedia Systems BBS at (206) 936-4082 in the files library in the
  90. technotes section in the mmaware.zip file.  BBS modem settings are 9600
  91. baud, no parity, 8 data bits, 1 stop bit.  It is also available from
  92. the WINSDK forum on CompuServe.
  93. Intended Audience
  94. This document should be read by Multimedia Producers as well as
  95. programmers using all types of tools.
  96. Questions?
  97. Please direct all questions, requests and problems with this technical
  98. note to the sysop of the MM BBS, or via FAX or mail to:
  99.  
  100. Multimedia Technical Support
  101. Microsoft Multimedia Group
  102. One Microsoft Way
  103. Redmond, WA 98052-6399
  104. FAX: 206 93MS-FAX
  105. Please let us know if you find this information useful.
  106.  
  107.                                    
  108.                         Classes of Applications
  109.  
  110. Multimedia applications fall loosely into two classes: those totally
  111. dependent on the multimedia APIs, and those that use them if they are
  112. available.   The latter is called being 'multimedia aware' because the
  113. application is 'aware' of the multimedia APIs and uses them if they are
  114. available.  Applications that don't provide Multimedia capabilities
  115. won't be purchased.
  116. Multimedia Dependent Applications.
  117.  
  118. An application that is 'multimedia dependent' requires the Multimedia
  119. APIs to be available.
  120.  
  121. Some applications only make sense in a Multimedia environment.  For
  122. example, a speak and spell tutor requires support for playing sounds.
  123. If the machine has no Multimedia support then the application cannot be
  124. run.  Attempting to run the application on a basic Windows 3.0 platform
  125. results in a dialog box telling the user that Windows can't find
  126. MMSYSTEM.DLL.  This isn't really a nice way to inform the user that we
  127. can't run his application, but it's the best we can do if it's linked
  128. with MMSYSTEM.LIB during creation.  It would be nice if we could inform
  129. the user that they needed the Multimedia extensions to use the
  130. application.  The best we can do is create applications which either
  131. fail gracefully or have reduced functionality if some feature they
  132. require is not available.
  133. Multimedia Aware Applications.
  134.  
  135. An application that is 'multimedia aware' will use the Multimedia APIs
  136. if they are available.
  137.  
  138. Instead of linking an application directly with the MMSYSTEM library,
  139. it can be linked with an intermediate library whose role is to
  140. determine the existence of a particular function in the system and link
  141. to it at run time if it exists.  If the function is not present then
  142. some default action can take place.  This may be as simple as returning
  143. an error code to inform the application that the call failed or it may
  144. be some code to emulate the required function.  The MM Sys BBS
  145. currently includes such a library, complete with source code and notes
  146. on how to use it.  See the Overview section for details on how to
  147. obtain this code.  An application constructed with this library is
  148. capable of running under regular Windows as well as Windows with
  149. Multimedia API Extensions including Windows 3.1.
  150.                                    
  151.                     Different Levels of Awareness.
  152.  
  153. Applications can be sensitive to the presence of the extensions or to
  154. individual components.  To illustrate this let's consider an
  155. application which displays text, has some animations, and uses
  156. waveform, MIDI and CD audio sounds in various places.  At first sight,
  157. this application seems doomed if no Multimedia support is available.
  158. However, let's expand things a bit and say that the application is some
  159. sort of encyclopedia in which the majority of the application consists
  160. of displaying text which is occasionally augmented by Multimedia
  161. inserts.  This application can provide most of its functionality on a
  162. regular Windows 3.0 platform since it only requires the normal Windows
  163. USER and GDI support to display its text.
  164.  
  165. In creating a version of this application which runs both under regular
  166. Windows and with the extensions, we need to consider not only whether
  167. the Multimedia extensions exist but also what support there might be
  168. for each of the data types we will want to render.  Is the CD audio
  169. device available?  Can the wave device handle the format I want?
  170.  
  171. In the simplest case, we could detect the presence of the extensions at
  172. run time and simply disable all the Multimedia features if the
  173. extensions were not found.  However it is still not valid to assume
  174. that all the devices we want to use are present, even if the extensions
  175. are found to exist.   It may well be that another application is
  176. running and is currently using one or more of the features we need.
  177. Coping with resource availability is discussed in the next section.
  178.                                    
  179.                     General Programming Guidelines
  180.  
  181. This section discusses important guidelines and issues in developing
  182. multimedia applications.
  183. Coping with Resource Availability.
  184.  
  185. The ideal solution is to only attempt to use a device or feature when
  186. it's needed and close it when it's no longer required.  If the resource
  187. is not available then either continue without it (gray out the button
  188. which plays sound etc.) or inform the user that they need to release it
  189. from some other application.
  190.  
  191. Unfortunately, this solution produces some large timing delays if
  192. opening a device causes any code to be loaded. This is the case when
  193. applications use MCI to access devices.  The MCI device handler DLL
  194. takes a little while to load and initialize.  Often, this is
  195. unacceptable in the application.
  196.  
  197. A good compromise is to open the device ahead of when it's required and
  198. release it when someone else needs it or when the application is
  199. terminated.  This has the advantage that your application will know if
  200. the device is available or not well before it needs to use it, thus
  201. avoiding the delays associated with code being loaded.  To do this
  202. well, your application must process any WM_ACTIVATEAPP messages it
  203. receives.  If it receives WM_ACTIVATEAPP with wParam set to zero, then
  204. the application is no longer the active one and it should close any
  205. devices it has open.  A subsequent WM_ACTIVATEAPP message with a non-
  206. zero wParam value indicates that the application is once more the
  207. active one and it should attempt to reopen any devices it needs.
  208.  
  209. The application can determine if each Multimedia feature it uses is
  210. available and selectively disable those parts which are not going to
  211. work. It can also optionally notify the user of this reduced
  212. functionality.
  213.  
  214. The key to creating a tolerant application in this environment is to be
  215. sure to check the error return code from every attempt to open a
  216. device.  In this way your application will avoid failing as the system
  217. configuration changes and you will be able to inform the user in either
  218. a direct way (dialog box) or a more subtle way (ex., dimmed buttons) of
  219. the loss of a feature.
  220. Yielding Resources to Other Applications.
  221.  
  222. It's important that applications which hold devices open for long
  223. periods process the WM_ACTIVATEAPP messages sent to them.  This allows
  224. other applications to use the Multimedia facilities.  For example,
  225. consider a game which allows the user to speak some of the parts by
  226. recording their own voice.  While playing the game, they may decide to
  227. bring up Sound Recorder to alter one of the files they recorded
  228. previously.  If the game won't yield the wave output device then the
  229. Sound Recorder won't function as the user expects.
  230.  
  231. As a rule applications shouldn't do things while they aren't active
  232. such as playing animations or sounds.  An exception to this rule might
  233. be an application like Music Box which plays audio CDs.  In this case
  234. it would be unreasonable behavior to stop playing the CD just because
  235. the user wanted to run some other application!  If your application
  236. needs to use the CD, and it's not available because some other
  237. application has it open, then you just have to tell the user about it.
  238.  
  239. The application should also allow the user a method, usually through a
  240. menu selection, to turn off certain multimedia features.  This
  241. particularly applies to sounds.  The user may want a background
  242. application to play MIDI files while he works, just like he may want to
  243. play a CD-Audio disc while he uses your application.  In addition, the
  244. user may get tired of hearing the same sounds from your application
  245. over and over again.
  246. Multimedia APIs Do Not Imply Multimedia Features
  247.  
  248. Windows 3.1 will include the multimedia API extensions.   What this
  249. means to an application is that the existence of MMSYSTEM.DLL does not
  250. necessarily mean the existence of any device drivers.  It's quite
  251. possible that the system is installed on a machine with no sound card.
  252. In fact the machine may have no Multimedia features at all.
  253.  
  254. Having Multimedia APIs does not imply that all the MPC standard
  255. features are available.  In addition, just because there is a CD-ROM
  256. does not mean it meets MPC specifications.  Your application should
  257. warn the user in the documentation that if he does not have MPC
  258. compatible hardware that application performance may suffer.
  259.  
  260. To survive in this world, your application must either fail gracefully
  261. at start up with a message, or be tolerant at run time of support being
  262. unavailable.
  263.  
  264. It is also important that you consider how your setup or installation
  265. program will be a part of this.  If your setup program finds no
  266. Multimedia support and consequently disables features of your
  267. application, then it's important that there is a mechanism to enable
  268. these features if the user adds a sound card (for example) at a later
  269. time.  This may simply mean re-running the setup program but you should
  270. consider putting this sort of detection into the start up code for the
  271. application itself.  Remember that you don't need to worry about
  272. exactly which sound driver gets added, simply that those APIs are now
  273. supported and this is easy to detect at run time.
  274.  
  275. Don't Assume Number of Drivers to be Constant
  276.  
  277. One further complication when determining the number of available
  278. drivers is that at some point, the system will have the facility added
  279. to load and unload drivers on demand.  This mechanism might be used to
  280. implement installable filters such as a 16 bit to 8 bit wave converter.
  281.  
  282. What this means is that the number of available drivers during the run
  283. time of your application may vary and it will not be sufficient to
  284. simply enumerate them when the application starts if you wish to make
  285. use of every available driver.
  286.  
  287.  
  288.