| blob | ba34538a04b3d91a78082c6c997819f16d131383 |
4 <para>
5 This file contains information about the implementation of the
6 multimedia layer of Wine.
7 </para>
9 <para>
10 The implementation can be found in the dlls/winmm/ directory (and in
11 many of its subdirectories), but also in dlls/msacm/ (for the
12 audio compression/decompression manager) and dlls/msvideo/ (for the
13 video compression/decompression manager).
14 </para>
19 <para>
20 The multimedia stuff is split into 3 layers. The low level (device
21 drivers), mid level (MCI commands) and high level abstraction layers.
22 The low level layer has also some helper DLLs (like the MSACM/MSACM32
23 and MSVIDEO/MSVFW32 pairs).
24 </para>
26 <para>
27 The low level layer may depend on current hardware and OS services
28 (like OSS on Unix). Mid level (MCI) and high level layers must be
29 written independently from the hardware and OS services.
30 </para>
32 <para>
33 There are two specific low level drivers (one for wave input/output,
34 another one for MIDI output only), whose role is:
35 <itemizedlist>
36 <listitem>
37 <para>
38 help choosing one low level driver between many
39 </para>
40 </listitem>
41 <listitem>
42 <para>
43 add the possibility to convert streams (ie ADPCM => PCM)
44 </para>
45 </listitem>
46 <listitem>
47 <para>
48 add the possibility to filter a stream (adding echo, equalizer...
49 to a wave stream), or modify the instruments that have to be
50 played (MIDI).
51 </para>
52 </listitem>
53 </itemizedlist>
54 </para>
56 <para>
57 All of those components are defined as DLLs (one by one).
58 </para>
60 </sect1>
65 <para>
66 Please note that native low level drivers are not currently supported
67 in Wine, because they either access hardware components or require
68 VxDs to be loaded; Wine does not correctly supports those two so far.
69 </para>
71 <para>
72 The following low level layers are implemented (as built-in DLLs):
73 </para>
75 <sect2>
78 <para>
79 MMSYSTEM and WINMM call the real low level audio driver using the
80 wodMessage/widMessage which handles the different requests.
81 </para>
83 <sect3>
86 <para>
87 The low level audio driver is currently only implemented for the
88 OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by
90 The presence of this driver is checked by configure (depends on the
92 dlls/winmm/wineoss/audio.c.
93 </para>
95 <para>
96 The implementation contains all features commonly used, but has
97 several problems (see TODO list).
98 </para>
100 <para>
101 Note that some Wine specific flag has been added to the wodOpen function,
102 so that the dsound DLL can share the /dev/dsp access. Currently, this
103 only provides mutual exclusion for both DLLs. Future extension could add
104 a virtual mixer between the two output streams.
105 </para>
107 <para>TODO:
108 <itemizedlist>
109 <listitem>
110 <para>
111 verify all functions for correctness
112 </para>
113 </listitem>
114 <listitem>
115 <para>
116 Add virtual mixer between wave-out and dsound interfaces.
117 </para>
118 </listitem>
119 </itemizedlist>
120 </para>
122 </sect3>
124 <sect3>
127 <para>
128 No other is available. Could think of Sun Audio, remote audio systems
129 (using X extensions, ...), ALSA, EsounD, ArTs...
130 </para>
132 </sect3>
134 </sect2>
136 <sect2>
139 <para>
140 MMSYSTEM and WINMM call the low level driver functions using the
141 midMessage and the modMessage functions.
142 </para>
144 <sect3>
147 <para>
148 The low level audio driver is currently only implemented for the
149 OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by
151 The presence of this driver is checked by configure (depends on the
153 MIDI is not supported on all OSes by OSS). Source code resides in
154 dlls/winmm/wineoss/midi.c
155 </para>
157 <para>
158 Both Midi in and Midi out are provided. The type of MIDI devices
159 supported is external MIDI port (requires an MIDI capable device -
161 instruments are in midiPatch.c).
162 </para>
164 <para>TODO:
165 <itemizedlist>
166 <listitem>
167 <para>
168 use better instrument definition for OPL/2 (midiPatch.c) or use
169 existing instrument definition (from playmidi or kmid) with a
170 .winerc option
171 </para>
172 </listitem>
173 <listitem>
174 <para>
175 have a look at OPL/3 ?
176 </para>
177 </listitem>
178 <listitem>
179 <para>
180 implement asynchronous playback of MidiHdr
181 </para>
182 </listitem>
183 <listitem>
184 <para>
185 implement STREAM'ed MidiHdr (question: how shall we share the code
186 between the midiStream functions in MMSYSTEM/WINMM and the code
187 for the low level driver)
188 </para>
189 </listitem>
190 <listitem>
191 <para>
192 use a more accurate read mechanism than the one of snooping on
193 timers (like select on fd)
194 </para>
195 </listitem>
196 </itemizedlist>
197 </para>
199 </sect3>
201 <sect3>
204 <para>
205 Could support other MIDI implementation for other sub systems (any
206 idea here ?)
207 </para>
209 <para>
210 Could also implement a software synthesizer, either inside Wine or
211 using using MIDI loop back devices in an external program (like
212 timidity). The only trouble is that timidity is GPL'ed...
213 </para>
215 </sect3>
217 </sect2>
219 <sect2>
222 <para>
223 MMSYSTEM and WINMM call the low level driver functions using the
224 mxdMessage function.
225 </para>
227 <sect3>
230 <para>
231 The current implementation uses the OpenSoundSystem mixer, and resides
232 in dlls/winmm/wineoss/mixer.c
233 </para>
235 <para>TODO:
236 <itemizedlist>
237 <listitem>
238 <para>
239 implement notification mechanism when state of mixer's controls
240 change
241 </para>
242 </listitem>
243 </itemizedlist>
244 </para>
246 </sect3>
248 <sect3>
251 <para>TODO:
252 <itemizedlist>
253 <listitem>
254 <para>
255 implement mixing low level drivers for other mixers (ALSA...)
256 </para>
257 </listitem>
258 </itemizedlist>
259 </para>
261 </sect3>
263 </sect2>
265 <sect2>
268 <para>
269 The AUX low level driver is the predecessor of the mixer driver
270 (introduced in Win 95).
271 </para>
273 <sect3>
276 <para>
277 The implementation uses the OSS mixer API, and is incomplete.
278 </para>
280 <para>TODO:
281 <itemizedlist>
282 <listitem>
283 <para>
284 verify the implementation
285 </para>
286 </listitem>
287 <listitem>
288 <para>
289 check with what is done in mixer
290 </para>
291 </listitem>
292 <listitem>
293 <para>
294 open question: shall we implement it on top of the low level mixer
295 functions ?
296 </para>
297 </listitem>
298 </itemizedlist>
300 </para>
302 </sect3>
304 </sect2>
306 <sect2>
309 <para>
310 All the OSS dependent functions are stored into the WineOSS DLL. It still
311 lack a correct installation scheme (as any multimedia device under Windows),
312 so that all the correct keys are created in the registry. This requires
313 an advanced model since, for example, the number of wave out devices can
314 only be known on the destination system (depends on the sound card driven
315 by the OSS interface). A solution would be to install all the multimedia
316 drivers through the SETUPX DLL; this is not doable yet (the multimedia
317 extension to SETUPX isn't written yet).
318 </para>
320 </sect2>
322 <sect2>
325 <para>
326 The API consists of the joy* functions found in dlls/winmm/joystick/joystick.c.
327 The implementation currently uses the Linux joystick device driver
328 API. It is lacking support for enhanced joysticks and has not been
329 extensively tested.
330 </para>
332 <para>TODO:
333 <itemizedlist>
334 <listitem>
335 <para>
336 better support of enhanced joysticks (Linux 2.2 interface is available)
337 </para>
338 </listitem>
339 <listitem>
340 <para>
341 support more joystick drivers (like the XInput extension)
342 </para>
343 </listitem>
344 <listitem>
345 <para>
346 should load joystick DLL as any other driver (instead of hardcoding)
347 the driver's name, and load it as any low lever driver.
348 </para>
349 </listitem>
350 </itemizedlist>
351 </para>
353 </sect2>
355 <sect2>
358 <para>
359 The Wave mapper device allows to load on-demand codecs in order to
360 perform software conversion for the types the actual low level driver
361 (hardware). Those codecs are provided through the standard ACM
362 drivers.
363 </para>
365 <sect3>
368 <para>
369 A first working implementation for wave out as been provided (wave in
370 exists, but doesn't allow conversion).
371 </para>
373 <para>
374 Wave mapper driver implementation can be found in dlls/winmm/wavemap/
375 directory. This driver heavily relies on MSACM and MSACM32 DLLs which
376 can be found in dlls/msacm and dlls/msacm32. Those DLLs load ACM
377 drivers which provide the conversion to PCM format (which is normally
378 supported by low level drivers). ADPCM, MP3... fit into the category
379 of non PCM formats.
380 </para>
382 <para>
383 There is currently no built-in ACM driver in Wine, so you must use
384 native ones if you're looking for non PCM playback.
385 </para>
387 <para>TODO:
388 <itemizedlist>
389 <listitem>
390 <para>
391 check for correctness and robustness
392 </para>
393 </listitem>
394 </itemizedlist>
395 </para>
396 </sect3>
398 <sect3>
401 <para>
402 Seems to work quite ok (using of course native MSACM/MSACM32 DLLs)
403 Some other testings report some issues while reading back the registry
404 settings.
405 </para>
407 </sect3>
409 </sect2>
411 <sect2>
414 <para>
415 Midi mapper allows to map each one of 16 MIDI channels to a specific
416 instrument on an installed sound card. This allows for example to
417 support different MIDI instrument definition (XM, GM...). It also
418 permits to output on a per channel basis to different MIDI renderers.
419 </para>
421 <sect3>
424 <para>
425 A built-in MIDI mapper can be found in dlls/winmm/midimap/. It partly
426 provides the same functionality as the Windows' one. It allows to pick up
427 destination channels (you can map a given channel to a specific playback
428 device channel (see the configuration bits for more details).
429 </para>
431 <para>TODO:
432 <itemizedlist>
433 <listitem>
434 <para>
435 implement the Midi mapper features (instrument on the fly modification)
436 if it has to be done as under Windows, it required parsing the midi
437 configuration files (didn't find yet the specs)
438 </para>
439 </listitem>
440 </itemizedlist>
441 </para>
443 </sect3>
445 <sect3>
448 <para>
449 The native midimapper from Win 98 works, but it requires a bunch of
450 keys in the registry which are not part of the Wine source yet.
451 </para>
453 <para>TODO:
454 <itemizedlist>
455 <listitem>
456 <para>
457 add native midimapper keys to the registry to let it run. This
458 will require proper multimedia driver installation routines.
459 </para>
460 </listitem>
461 </itemizedlist>
462 </para>
464 </sect3>
466 </sect2>
468 </sect1>
473 <para>
474 The mid level drivers are represented by some common API functions,
475 mostly mciSendCommand and mciSendString. See status in chapter 3 for
476 more information. Wine implements several MCI mid level drivers
477 (status is given for both built-in and native implementation):
478 </para>
480 <para>TODO: (apply to all built-in MCI drivers)
481 <itemizedlist>
482 <listitem>
483 <para>
484 use MMSYSTEM multitasking caps instead of the home grown
485 </para>
486 </listitem>
487 </itemizedlist>
488 </para>
491 <sect2>
494 <sect3>
497 <para>
498 The currently best implementation is the MCI CDAUDIO driver that can
499 be found in dlls/winmm/mcicda/mcicda.c. The implementation is mostly
500 complete, there have been no reports of errors. It makes use of
501 misc/cdrom.c Wine internal cdrom interface.
502 This interface has been ported on Linux, FreeBSD and NetBSD. (Sun
503 should be similar, but are not implemented.)
504 </para>
506 <para>
507 A very small example of a cdplayer consists just of the line
509 </para>
511 <para>TODO:
512 <itemizedlist>
513 <listitem>
514 <para>
515 add support for other cdaudio drivers (Solaris...)
516 </para>
517 </listitem>
518 <listitem>
519 <para>
520 add support for multiple cdaudio devices (plus a decent
521 configuration scheme)
522 </para>
523 </listitem>
524 <listitem>
525 <para>
526 The DLL is not cleanly separated from the NTDLL DLL. The CDROM
527 interface should be exported someway (or stored in a Wine only DLL)
528 </para>
529 </listitem>
530 </itemizedlist>
531 </para>
533 </sect3>
535 <sect3>
538 <para>
539 Native MCICDA works also correctly... It uses the MSCDEX traps (on int
540 2f). However, some commands (like seeking) seem to be broken.
541 </para>
543 </sect3>
545 </sect2>
547 <sect2>
550 <sect3>
553 <para>
554 The implementation is rather complete and can be found in
555 dlls/winmm/mciwave/audio.c. It uses the low level audio API (although
556 not abstracted correctly).
557 </para>
559 <para>FIXME:
560 <itemizedlist>
561 <listitem>
562 <para>
563 The MCI_STATUS command is broken.
564 </para>
565 </listitem>
566 </itemizedlist>
567 </para>
569 <para>TODO:
570 <itemizedlist>
571 <listitem>
572 <para>
573 check for correctness
574 </para>
575 </listitem>
576 <listitem>
577 <para>
578 better use of asynchronous playback from low level
579 </para>
580 </listitem>
581 <listitem>
582 <para>
583 better implement non waiting command (without the MCI_WAIT flag).
584 </para>
585 </listitem>
586 </itemizedlist>
587 </para>
589 </sect3>
591 <sect3>
594 <para>
595 Native MCIWAVE works also correctly.
596 </para>
598 </sect3>
600 </sect2>
602 <sect2>
605 <sect3>
608 <para>
609 The implementation can be found in dlls/winmm/mciseq/mcimidi.c. Except
610 from the Record command, should be close to completion (except for non
611 blocking commands, as many MCI drivers).
612 </para>
614 <para>TODO:
615 <itemizedlist>
616 <listitem>
617 <para>
618 implement it correctly
619 </para>
620 </listitem>
621 <listitem>
622 <para>
623 finish asynchronous commands (especially for reading/record)
624 </para>
625 </listitem>
626 <listitem>
627 <para>
628 better implement non waiting command (without the MCI_WAIT flag).
629 </para>
630 </listitem>
631 <listitem>
632 <para>
633 implement the recording features
634 </para>
635 </listitem>
636 </itemizedlist>
637 </para>
639 </sect3>
641 <sect3>
644 <para>
645 Native MCIMIDI has been working but is currently blocked by scheduling
646 issues (mmTaskXXX no longer work).
647 </para>
648 <para>FIXME:
649 <itemizedlist>
650 <listitem>
651 <para>
652 midiStreamPlay get from time to time an incorrect MidiHdr when
653 using the native MCI sequencer
654 </para>
655 </listitem>
656 </itemizedlist>
657 </para>
659 </sect3>
661 </sect2>
663 <sect2>
666 <sect3>
669 <para>
670 The implementation is in dlls/winmm/mcianim/.
671 </para>
673 <para>TODO:
674 <itemizedlist>
675 <listitem>
676 <para>
677 implement it, probably using xanim or something similar.
678 </para>
679 </listitem>
680 </itemizedlist>
681 </para>
683 </sect3>
685 <sect3>
688 <para>
689 Native MCIANIM is reported to work (but requires native video DLLs
690 also, even though the built-in video DLLs start to work correctly).
691 </para>
693 </sect3>
695 </sect2>
697 <sect2>
700 <sect3>
703 <para>
704 The implementation is in dlls/winmm/mcianim/. Basic features are present,
705 simple playing is available, even if lots remain to be done. It rather
706 heavily relies on MSVIDEO/MSVFW32 DLLs pair to work.
707 </para>
709 <para>TODO:
710 <itemizedlist>
711 <listitem>
712 <para>
713 finish the implementation
714 </para>
715 </listitem>
716 <listitem>
717 <para>
718 fix the audio/video synchronization issue
719 </para>
720 </listitem>
721 </itemizedlist>
722 </para>
724 </sect3>
726 <sect3>
729 <para>
730 Native MCIAVI is reported to work (but requires native video DLLs
731 also). Some files exhibit some deadlock issues anyway.
732 </para>
734 </sect3>
736 </sect2>
738 </sect1>
743 <para>
744 The rest (basically the MMSYSTEM and WINMM DLLs entry points). It also
745 provides the skeleton for the core functionality for multimedia
746 rendering. Note that native MMSYSTEM and WINMM do not currently work
747 under Wine and there is no plan to support them (it would require to
748 also fully support VxD, which is not done yet).
749 Moreover, native DLLs require 16 bit MCI and low level drivers. Wine
750 implements them as 32 bit drivers.
752 </para>
754 <para>TODO:
755 <itemizedlist>
756 <listitem>
757 <para>
758 it seems that some program check what's installed in registry
759 against value returned by drivers. Wine is currently broken
760 regarding this point.
761 </para>
762 </listitem>
763 <listitem>
764 <para>
765 add clean-up mechanisms when process detaches from MM DLLs
766 </para>
767 </listitem>
768 <listitem>
769 <para>
771 </para>
772 </listitem>
773 <listitem>
774 <para>
775 check thread-safeness for MMSYSTEM and WINMM entry points
776 </para>
777 </listitem>
778 <listitem>
779 <para>
780 unicode entry points are badly supported
781 </para>
782 </listitem>
783 </itemizedlist>
784 </para>
786 <sect2>
789 <para>
790 Implementation of what is needed to load/unload MCI drivers, and to
791 pass correct information to them. This is implemented in
792 dlls/winmm/mci.c. The mciSendString function uses command strings,
793 which are translated into normal MCI commands as used by
794 mciSendCommand with the help of command tables. The API can be found
795 in dlls/winmm/mmsystem.c and dlls/winmm/mci.c. The functions there
796 (mciOpen,mciSysInfo) handle mid level driver allocation and calls. The
797 implementation is not complete.
798 </para>
800 <para>
801 MCI drivers are seen as regular Wine modules, and can be loaded (with
802 a correct load order between builtin, native, so), as any
803 other DLL. Please note, that MCI drivers module names must bear the
804 .drv extension to be correctly understood.
805 </para>
807 <para>
808 The list of available MCI drivers is obtained as follows:
809 1. key 'mci' in [option] section from .winerc (or wineconf)
810 mci=CDAUDIO:SEQUENCER gives the list of MCI drivers (names, in
811 uppercase only) to be used in Wine.
812 2. This list, when defined, supersedes the mci key in
813 c:\windows\system.ini
814 </para>
816 <para>
817 Note that native VIDEODISC crashes when the module is loaded, which
818 occurs when the MCI procedures are initialized. Make sure that this is
819 not in the list from above. Try adding:
820 mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
821 to the [options] section of the wine config file.
822 </para>
824 <para>TODO:
825 <itemizedlist>
826 <listitem>
827 <para>
828 correctly handle the MCI_ALL_DEVICE_ID in functions.
829 </para>
830 </listitem>
831 <listitem>
832 <para>
834 </para>
835 </listitem>
836 <listitem>
837 <para>
838 MCI_SOUND is not handled correctly (should not be sent to MCI
839 driver => same behavior as MCI_BREAK)
840 </para>
841 </listitem>
842 <listitem>
843 <para>
844 implement auto-open feature (ie, when a string command is issued
845 for a not yet opened device, MCI automatically opens it)
846 </para>
847 </listitem>
848 </itemizedlist>
849 </para>
851 </sect2>
853 <sect2>
856 <para>
857 Multi-tasking capabilities used for the MCI drivers are provided in
858 dlls/winmm/mmsystem.c.
859 </para>
861 <para>TODO:
862 <itemizedlist>
863 <listitem>
864 <para>
865 mmTaskXXX functions are currently broken because the 16 loader does
866 not support binary command lines => provide Wine's own mmtask.tsk not
867 using binary command line.
868 </para>
869 </listitem>
870 <listitem>
871 <para>
872 the Wine native MCI drivers should use the mmThreadXXX API (but since
873 all built-in MCI drivers are 32 bit, this would require a special
874 flag to mark 32 bit entry points)
875 </para>
876 </listitem>
877 </itemizedlist>
878 </para>
880 </sect2>
882 <sect2>
885 <para>
886 It currently uses a service thread, run in the context of the calling
887 process, which should correctly mimic Windows behavior.
888 </para>
890 <para>TODO:
891 <itemizedlist>
892 <listitem>
893 <para>
894 Check if minimal time is satisfactory for most programs.
895 </para>
896 </listitem>
897 <listitem>
898 <para>
899 current implementation may let a timer tick (once) after it has
900 been destroyed
901 </para>
902 </listitem>
903 </itemizedlist>
904 </para>
906 </sect2>
908 <sect2>
911 <para>
912 The API consists of the mmio* functions found in dlls/winmm/mmio.c.
913 Seems to work ok in most of the cases. There's some linear/segmented
914 issues with 16 bit code. There are also some bugs when writing MMIO
915 files.
916 </para>
918 </sect2>
920 <sect2>
923 <para>
924 Seem to work correctly.
925 </para>
927 </sect2>
929 </sect1>
934 <para>
935 Currently, multimedia configuration heavily relies on Win 3.x
936 configuration model.
937 </para>
939 <sect2>
942 <para>
943 Since all multimedia drivers (MCI, low level ones, ACM drivers,
944 mappers) are, at first, drivers they need to appear in the [mci] or
945 [mci32] section of the system.ini file.
946 Since all drivers are, at first, DLLs, you can choose to load their
947 Wine's (built-in) or Windows (native) version.
948 </para>
950 </sect2>
952 <sect2>
955 <para>
956 A default [mci] section (in system.ini) looks like (see the note above
957 on videodisc):
958 </para>
960 <screen>
961 [mci]
962 cdaudio=mcicda.drv
963 sequencer=mciseq.drv
964 waveaudio=mciwave.drv
965 avivideo=mciavi.drv
966 videodisc=mcipionr.drv
967 vcr=mcivisca.drv
968 MPEGVideo=mciqtz.drv
969 </screen>
971 <para>
972 By default, the list of loadable MCI drivers will be made of those
973 drivers (in the [mci] section).
974 </para>
976 <para>
977 The list of loadable (recognized) MCI drivers can be altered in the
978 [option] section of the wine config file, like:
979 mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
980 </para>
982 <para>TODO:
983 <itemizedlist>
984 <listitem>
985 <para>
986 use a default registry setting to bypass this (ugly) configuration
987 model
988 </para>
989 </listitem>
990 </itemizedlist>
991 </para>
993 </sect2>
995 <sect2>
998 <para>
999 Configuration of low level drivers is done with the Wine configuration file.
1000 Default keys are provided in winedefault.reg.
1001 </para>
1003 <para>
1004 The registry keys used here differ from the Windows' one. Using the Windows' one
1005 would require implementing something equivalent to a (real) driver installation.
1006 Even if this would be necessary in a few cases (mainly using MS native multimedia)
1007 modules, there's no real need so far (or it hasn't been run into yet).
1008 </para>
1010 <para>
1011 See the configuration part of the User's Guide for more details.
1012 </para>
1014 </sect2>
1016 <sect2>
1019 <para>
1020 The Midi mapper configuration is the same as on Windows 9x. Under the key
1021 <screen>
1022 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap
1023 </screen>
1024 if the 'UseScheme' value is not set, or is set to a null value, the midi
1025 mapper will always use the driver identified by the 'CurrentInstrument'
1026 value. Note: Wine (for simplicity while installing) allows to define
1027 'CurrentInstrument' as "#n" (where n is a number), whereas Windows only
1028 allows the real device name here. If UseScheme is set to a non null value,
1029 'CurrentScheme' defines the name of the scheme to map the different channels.
1030 All the schemes are available with keys like
1031 <screen>
1032 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\%name_of_scheme%
1033 </screen>
1034 For every scheme, under this key, will be a sub-key (which name is usually
1035 a two digit index, starting at 00). Its default value is the name of the
1036 output driver, and the value 'Channels' lists all channels (of the 16
1037 standard MIDI ones) which have to be copied to this driver.
1038 </para>
1040 <para>
1041 To provide enhanced configuration and mapping capabilities, each driver
1042 can define under the key
1043 <screen>
1044 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Ports\%driver_name%
1045 </screen>
1046 a link to and .IDF file which allows to remap channels internally (for
1048 controllers values. See the source file dlls/winmm/midimap/midimap.c
1049 for the details (this isn't implemented yet).
1050 </para>
1051 </sect2>
1053 <sect2>
1056 <para>
1057 To be done (use the same mechanism as MCI drivers configuration).
1058 </para>
1060 </sect2>
1062 <sect2>
1065 <para>
1066 To be done (use the same mechanism as MCI drivers configuration).
1067 </para>
1069 </sect2>
1071 </sect1>
1076 <sect2>
1079 <screen>
1080 |
1081 Kernel space | Client applications
1082 |
1083 | | | ^ ^ | | | |
1085 | | v | | | v | v
1086 | +----|-----------|---------|------------|-------+
1087 | | | | | | | WinMM.dll
1088 | | | | | | | 32 bit
1089 | +----|-----------|---------|------------|-------+
1090 | | | | ^ | | |
1093 | | v v v | | v v v
1094 | | +---------------+---+-------------+-------------+
1095 | | | waveInXXX | | mciXXX | *playSound* |
1096 | | | waveOutXXX | | | mmioXXX |
1097 | | | midiInXXX | | | timeXXX |
1098 | | | midiOutXXX | | | driverXXX |
1099 | | | midiStreamXXX | | | | MMSystem.dll
1100 | | | mixerXXX | | | | 16 bit
1101 +--------+ | | | auxXXX +---+ +---+ mmThread| |
1102 |MMDEVLDR|<------->| joyXXX | Call back | mmTask | |
1103 +--------+ | | +-----------+-----------+---------+-------------+
1104 ^ | | | ^ ^ | ^
1106 v | | v | | v |
1107 +--------+ | | +-------------+ +----------+
1108 | VxD |<------->| *.drv | | mci*.drv |
1109 +--------+ | | +--------------+ +-----------+
1110 | | | msacm.drv | | mciwave |
1111 | | +--------------+ +-----------+
1112 | | | midimap.drv | | mcimidi |
1113 | | +-------------+ +-----------+
1114 | | Low-level drivers | ... | MCI drivers
1115 | | +----------+
1116 | | |
1117 | | |<16
1118 | +-------------------------------+
1119 |
1120 </screen>
1122 <para>
1123 The important points to notice are:
1124 <itemizedlist>
1125 <listitem>
1126 <para>
1127 all drivers (and most of the core code) is 16 bit
1128 </para>
1129 </listitem>
1130 <listitem>
1131 <para>
1132 all hardware (or most of it) dependent code reside in the kernel
1133 space (which is not surprising)
1134 </para>
1135 </listitem>
1136 </itemizedlist>
1137 </para>
1139 </sect2>
1141 <sect2>
1144 <screen>
1145 |
1146 Kernel space | Client applications
1147 |
1148 | | | ^ ^ | | | |
1150 | | | | | | | | |
1151 | +------+ | | | | | | | |
1153 | | v v v | | v v v v
1154 | | +---------------+---+-------------+-------------+
1155 | | | waveInXXX | | mciXXX | *playSound* |
1156 | | | waveOutXXX | | | mmioXXX | WinMM.dll
1157 | | | midiInXXX | | | timeXXX | 32 bit
1158 | | | midiOutXXX | | | driverXXX |
1159 | | | midiStreamXXX | | | | MMSystem.dll
1160 | | | mixerXXX | | | | 16 bit
1161 | | | auxXXX +---+ +---+ mmThread| |
1162 | | | joyXXX | Call back | mmTask | |
1163 | | +-----------+-----------+---------+-------------+
1164 | | || ^ ^ || ^^
1166 | | vv |<32>| vv ||
1167 +---------+ | | +-------------+ +----------+
1168 |HW driver|<------->| *.drv | | mci*.drv |
1169 +---------+ | | +--------------+ +-----------+
1170 | | | msacm.drv | | mciwave |
1171 | | +--------------+ +-----------+
1172 | | | midimap.drv | | mcimidi |
1173 | | +-------------+ +-----------+
1174 | | Low-level drivers | ... | MCI drivers
1175 | | +----------+
1176 | | |
1178 | +-------------------------------+
1179 |
1180 </screen>
1182 <para>
1183 From the previous drawings, the most noticeable differences are:
1184 <itemizedlist>
1185 <listitem>
1186 <para>
1188 </para>
1189 </listitem>
1190 <listitem>
1191 <para>
1193 </para>
1194 </listitem>
1195 <listitem>
1196 <para>
1197 MMSystem and WinMM will be hosted in a single elfglue library
1198 </para>
1199 </listitem>
1200 <listitem>
1201 <para>
1202 no link between the MMSystem/WinMM pair on kernel space shall
1203 exist. For example, there will be a low level driver to talk to a
1204 UNIX OSS (Open Sound System) driver
1205 </para>
1206 </listitem>
1207 <listitem>
1208 <para>
1209 all built-in drivers (low-level and MCI) will be written as 32 bit
1210 drivers
1211 </para>
1212 </listitem>
1213 <listitem>
1214 <para>
1215 all native drivers will be 16 bits drivers
1216 </para>
1217 </listitem>
1218 </itemizedlist>
1219 </para>
1221 </sect2>
1223 </sect1>
1228 <sect2>
1232 </sect2>
1234 <sect2>
1238 </sect2>
1240 <sect2>
1243 <para>
1244 The MSACM/MSACM32 keeps some data cached for all known ACM
1245 drivers. Under the key
1246 <screen>
1247 Software\Microsoft\AudioCompressionManager\DriverCache\<driver
1248 name>
1249 </screen>
1250 are kept for values:
1251 <itemizedlist>
1252 <listitem>
1253 <para>
1254 aFormatTagCache which contains an array of
1255 DWORD. There are two DWORDs per cFormatTags
1256 entry. The first DWORD contains a format tag
1257 value, and the second the associated maximum
1258 size for a WAVEFORMATEX structure.
1259 (Fields dwFormatTag and cbFormatSize from
1260 ACMFORMATDETAILS)
1261 </para>
1262 </listitem>
1263 <listitem>
1264 <para>
1265 cFilterTags contains the number of tags supported by the driver
1266 for filtering.
1267 </para>
1268 </listitem>
1269 <listitem>
1270 <para>
1271 cFormatTags contains the number of tags support
1272 by the driver for conversions.
1273 </para>
1274 </listitem>
1275 <listitem>
1276 <para>
1277 fdwSupport (the same as the one returned from
1278 acmDriverDetails).
1279 </para>
1280 </listitem>
1281 </itemizedlist>
1282 </para>
1284 <para>
1285 The cFilterTags, cFormatTags, fdwSupport are the same
1286 values as the ones returned from acmDriverDetails
1287 function.
1288 </para>
1289 </sect2>
1290 </sect1>
1293 </chapter>
1295 <!-- Keep this comment at the end of the file
1296 Local variables:
1297 mode: sgml
1298 sgml-parent-document:("wine-devel.sgml" "set" "book" "part" "chapter" "")
1299 End:
1300 -->