ReceiveTempSMS
/
Sweden-Number
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated, added chapter on configuration and architecture.

This commit is contained in:
Eric Pouech 1999-12-08 03:26:58 +00:00 committed by Alexandre Julliard
parent 8ee45ac7d7
commit 3393730f96
1 changed files with 523 additions and 283 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

806
documentation/status/multimedia
View File

@ -1,358 +1,598 @@
This file contains information about the implementation of the
multimedia layer of WINE.
The libraries consist of MMSYSTEM.DLL (win16), WINMM.DLL (win32) and This file contains information about the implementation of the
some (abstracted, not Windows compatible) lowlevel drivers. The multimedia layer of WINE. The libraries consist of MMSYSTEM.DLL
implementation can be found in the multimedia/ subdirectory. (win16), WINMM.DLL (win32) and some (abstracted, not Windows
compatible) low level drivers.
The multimedia stuff is split into 3 layers. The lowlevel (device
drivers), midlevel (MCI commands) and highlevel abstraction layers. The implementation can be found in the dlls/winmm/ sub directory.
The lowlevel may depend on current hardware and OS services (like 0. Overview
OSS). Mid-level and high-level must be written independantly from the ===========
hardware and OS services.
The multimedia stuff is split into 3 layers. The low level (device
1. Lowlevel layers drivers), mid level (MCI commands) and high level abstraction layers.
==================
The low level may depend on current hardware and OS services (like
Please note that native low-level drivers are not currently OSS). Mid level (MCI) and high level must be written independently
supported in WINE, because they either access hardware composants from the hardware and OS services.
or require VxDs to be loaded; WINE does not correctly supports There are two specific low level drivers call mappers (for wave and
those two so far. +midi) whose role is to :
* help choosing one low level driver between many
Following lowlevel layers are implemented: * add the possibility to convert stream (ie ADPCM => PCM)
* add the possibility to filter a stream (adding echo, equalizer...)
1.1 (Waveform) Audio
-------------------- All of those components are defined as DLLs (one by one) and are
candidate for dllglue migration.
MMSYSTEM and WINMM call the real lowlevel audiodriver using
the wodMessage/widMessage function in multimedia/audio.c, which 1. Low level layers
handles the different requests. ===================
1.1.1 OSS implementation Please note that native low level drivers are not currently supported
in WINE, because they either access hardware components or require
The lowlevel audio driver is currently only implemented for the VxDs to be loaded; WINE does not correctly supports those two so far.
OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels
by 4Front Technologies (http://www.4front-tech.com/). The presence The following low level layers are implemented:
of this driver is checked by configure (depends on the
<sys/soundcard.h> file). 1.1 (Wave form) Audio
---------------------
MMSYSTEM and WINMM call the real low level audio driver using the
wodMessage/widMessage which handles the different requests.
1.1.1 OSS implementation
The low level audio driver is currently only implemented for the
OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by
[1]4Front Technologies. The presence of this driver is checked by
configure (depends on the <sys/soundcard.h> file). Source code resides
in dlls/winmm/wineoss/audio.c,
The implementation contains all features commonly used, but has The implementation contains all features commonly used, but has
several problems (see TODO list). several problems (see TODO list).
TODO: TODO:
- add asynchronous reads (must use threads) as done for writes * add asynchronous reads [recording] (must use threads) as done for
- verify all functions for correctness writes [playing]
- add drivers for other soundsystems (Sun Audio, remote audio * verify all functions for correctness
systems (using X extensions, ...), ALSA * looping of WaveHdr will fail
- WaveHdr must be sent though mmsystem.c to get the linear * share access to /dev/dsp with dsound interface (either on a
address set correctly. An application calling directly descriptor basis, or using a virtual mixer between different wave
(wod|wid)Message will fail inputs. EsounD provides this type of capability).
1.1.2 Wave mapper 1.1.2 Other sub systems
The Wave mapper device allows to load on-demand codecs to perform None are available. Could think of Sun Audio, remote audio systems
software conversion for the types the actual low level driver (using X extensions, ...), ALSA, EsounD
(hardware) does not support. Those codecs are provided thru the
standard ACM drivers.
Wave mapper driver implementation has not started. Core DLL for ACM
support can be found in dlls/msacm
TODO:
- implement wave mapper
- don't forget to fix builtin ms acm drivers loading which has
been disabled.
1.2 MIDI 1.2 MIDI
-------- --------
MMSYSTEM and WINMM call the lowlevel driver functions in MMSYSTEM and WINMM call the low level driver functions using the
multimedia/midi.c using the midMessage and the modMessage midMessage and the modMessage functions.
functions.
1.2.1 OSS driver
1.2.1 OSS driver
The low level audio driver is currently only implemented for the
The lowlevel audio driver is currently only implemented for the OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by
OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels [1]4Front Technologies . The presence of this driver is checked by
by 4Front Technologies (http://www.4front-tech.com/). The presence configure (depends on the <sys/soundcard.h> file, and also some
of this driver is checked by configure (depends on the specific defines because MIDI is not supported on all OSes by OSS).
<sys/soundcard.h> file, and also some specfic defines because MIDI Source code resides in dlls/winmm/wineoss/midi.c
is not supported on all OSes by OSS).
Both Midi in and Midi out are provided. The type of MIDI devices Both Midi in and Midi out are provided. The type of MIDI devices
supported is external MIDI port (requires an MIDI capable device - supported is external MIDI port (requires an MIDI capable device -
keyboard...) and OPL/2 synthesis (the OPL/2 patches for all keyboard...) and OPL/2 synthesis (the OPL/2 patches for all
instruments are in midiPatch.c). instruments are in midiPatch.c).
TODO: TODO:
- Do not implement a software synthesizer. This should be done * use better instrument definition for OPL/2 (midiPatch.c) or use
using MIDI loopback devices in an external program (like existing instrument definition (from playmidi or kmid) with a
timidity). The only trouble is that timidity is GPL'ed... .winerc option
- use better instrument definition for OPL/2 (midiPatch.c) or * have a look at OPL/3 ?
use existing instrument definition (from playmidi or kmid) * implement asynchronous playback of MidiHdr
with a .winerc option * implement STREAM'ed MidiHdr (question: how shall we share the code
- have a look at OPL/3 ? between the midiStream functions in MMSYSTEM/WINMM and the code
- MidiHdr must be sent though mmsystem.c to get the linear for the low level driver)
address set correctly. An application calling directly * use a more accurate read mechanism than the one of snooping on
(wod|wid)Message will fail timers (like select on fd)
- implement asynchronous playback of MidiHdr (regular and/or
stream) 1.2.2 Other sub systems
- use a more accurate read mechanism than the one of snooping
on timers Could support other midi implementation for other sub systems (any
idea here ?)
1.2.2 MIDI mapper
Could also implement a software synthesizer, either inside Wine or
Midi mapper allows to map each one of 16 MIDI channels to a using using MIDI loop back devices in an external program (like
specific instrument on an installed sound card. This allows for timidity). The only trouble is that timidity is GPL'ed...
example to support different MIDI instrument definition (XM,
GM...). It also permits to output on a per channel basis to
different MIDI renderers.
TODO:
- implement the Midi mapper
1.3 Mixer 1.3 Mixer
--------- ---------
MMSYSTEM and WINMM call the lowlevel driver functions in MMSYSTEM and WINMM call the low level driver functions using the
multimedia/mixer.c using the mixMessage function. mixMessage function.
1.3.1 OSS implementation 1.3.1 OSS implementation
The current implementation uses the OpenSoundSystem mixer. The current implementation uses the OpenSoundSystem mixer, and resides
in dlls/winmm/wineoss/mixer.c
TODO: TODO:
- implement mixing mute functionality for OSS. * implement notification mechanism when state of mixer's controls
- implement mixing lowlevel drivers for other mixers (ALSA...) change
- implement notification mechanism when state of mixer's
controls change 1.3.2 Other sub systems
- handlers used for mixer are currently poorly implemented
TODO:
* implement mixing low level drivers for other mixers (ALSA...)
1.4 AUX 1.4 AUX
------- -------
The AUX low level driver is the predecessor of the mixer driver
(introduced in Win 95).
The API consists of the aux* functions found in 1.4.1 OSS driver
multimedia/mmsystem.c. They call auxMessage in multimedia/mmaux.c.
The aux* functions are the predecessor of the mixer* functions.
1.4.1 OSS driver
The implementation uses the OSS mixer API, and is incomplete. The implementation uses the OSS mixer API, and is incomplete.
TODO: TODO:
- verify the implementation * verify the implementation
- check with what is done in mixer * check with what is done in mixer
- open question: shall we implement it on top of the low level * open question: shall we implement it on top of the low level mixer
mixer functions ? functions ?
1.7 JOYSTICK 1.5 Joystick
------------ ------------
The API consists of the joy* functions found in
multimedia/joystick.c. The implementation currently uses the Linux
joystick device driver API. It is lacking support for enhanced
joysticks and has not been extensively tested.
The API consists of the joy* functions found in dlls/winmm/joystick.c.
The implementation currently uses the Linux joystick device driver
API. It is lacking support for enhanced joysticks and has not been
extensively tested.
TODO: TODO:
- better support of enhanced joysticks * better support of enhanced joysticks
- support more joystick drivers (like the XInput extension) * support more joystick drivers (like the XInput extension)
* should make joystick a separate DLL (impact also on
WINMM/MMSYSTEM), or a real low level driver, as it is on Windows
1.6 Wave mapper (msacm.drv)
---------------------------
2. Midlevel drivers (MCI) The Wave mapper device allows to load on-demand codecs in order to
========================= perform software conversion for the types the actual low level driver
(hardware). Those codecs are provided through the standard ACM
drivers.
The midlevel drivers are represented by some common API functions,
mostly mciSendCommand and mciSendString. 1.6.1 Build-in
See status in chapter 3 for more information.
A first working implementation for wave out as been provided (wave in
WINE implements several MCI midlevel drivers (status is given for exists, but doesn't allow conversion).
both builtin and native implementation): Wave mapper driver implementation can be found in dlls/winmm/wavemap/
directory. This driver heavily relies on MSACM and MSACM32 DLLs which
TODO: (apply to all builtin MCI drivers) can be found in dlls/msacm and dlls/msacm32. Those DLLs load ACM
- move mci drivers as regular DLLs (loading in wine, drivers which provide the conversion to PCM format (which is normally
elfglue...) supported by low level drivers). ADPCM, MP3... fit into the category
of non PCM formats.
There is currently no builtin ACM driver in Wine, so you must use
native ones if you're looking for non PCM playback.
In order to use native ACM drivers to play non PCM files, you must use
-dll msacm,msacm32,msacm.drv=b. Note that this code is not complete
yet, and may cause problems. sndrec32 and mplayer from Win95 appear to
work reasonably well though.
TODO:
* do wave in
* check for correctness and robustness
1.6.2 Native
Seems to work quite ok (using of course native MSACM/MSACM32 DLLs)
Some other testings report some issues while reading back the registry
settings.
1.7 MIDI mapper
---------------
Midi mapper allows to map each one of 16 MIDI channels to a specific
instrument on an installed sound card. This allows for example to
support different MIDI instrument definition (XM, GM...). It also
permits to output on a per channel basis to different MIDI renderers.
1.7.1 Built-in
A builtin MIDI mapper can be found in dlls/winmm/midimap. It only
provides the pickup of an existing MIDI low level driver for playback.
TODO:
* implement the Midi mapper features (channel / instrument on the
fly modification)
1.7.2 Native
Currently, the native midimapper i'm using is not working (mainly
because it reads low level drivers configuration from registry).
TODO:
* let native midimapper driver load
2. Mid level drivers (MCI)
==========================
The mid level drivers are represented by some common API functions,
mostly mciSendCommand and mciSendString. See status in chapter 3 for
more information. WINE implements several MCI mid level drivers
(status is given for both built-in and native implementation):
TODO: (apply to all built-in MCI drivers)
* use mmsystem multitasking caps instead of the home grown
2.1 CDAUDIO 2.1 CDAUDIO
----------- -----------
2.1.1 Builtin
2.1.1 Built-in
The currently best implementation is the MCI CDAUDIO driver that can The currently best implementation is the MCI CDAUDIO driver that can
be found in multimedia/mcicda.c. The implementation is mostly be found in dlls/winmm/mcicda/mcicda.c. The implementation is mostly
complete, there have been no reports of errors. complete, there have been no reports of errors. It makes use of
misc/cdrom.c Wine internal cdrom interface.
It makes use of misc/cdrom.c Wine internal cdrom interface. This This interface has been ported on Linux, FreeBSD and NetBSD. (Sun
interface has been ported on Linux, FreeBSD and NetBSD. should be similar, but are not implemented.)
(Sun should be similair, but are not implemented.)
A very small example of a cdplayer consists just of the line A very small example of a cdplayer consists just of the line
mciSendString("play cdaudio",NULL,0,0); mciSendString("play cdaudio",NULL,0,0);
2.1.2 Native
Native MCICDA works also correctly... It uses the mscdex traps (on
int 2f).
TODO: TODO:
- add support for other cdaudio drivers (Solaris...) * add support for other cdaudio drivers (Solaris...)
* add support for multiple cdaudio devices
2.1.2 Native
Native MCICDA works also correctly... It uses the mscdex traps (on int
2f).
2.2 MCIWAVE 2.2 MCIWAVE
----------- -----------
2.2.1 Built-in
The implementation is rather complete and can be found in
dlls/winmm/mciwave/audio.c. It uses the low level audio API (although
not abstracted correctly).
2.2.1 Builtin FIXME:
* The MCI_STATUS command is broken.
The implementation is rather complete and can be found in
multimedia/audio.c. TODO:
It uses the lowlevel audio API (although not abstracted * check for correctness
correctly). * better use of asynchronous playback from low level
* record has to be checked
FIXME: * MCI_CUE command is broken
- The MCI_STATUS command is broken. * better implement non waiting command (without the MCI_WAIT flag).
TODO: 2.2.2 Native
- check for correctness
- better use of asynchronous playback from low level
- record has to be checked
- MCI_CUE command is broken
- better implement non waiting command (without the MCI_WAIT
flag).
2.2.2 Native
Native MCIWAVE works also correctly. Native MCIWAVE works also correctly.
2.3 MCISEQ (MIDI sequencer) 2.3 MCISEQ (MIDI sequencer)
--------------------------- ---------------------------
2.3.1 Builtin
The implementation can be found in multimedia/midi.c. Except from 2.3.1 Built-in
the Record command, should be close to completion (except for non
The implementation can be found in dlls/winmm/mciseq/mcimidi.c. Except
from the Record command, should be close to completion (except for non
blocking commands). blocking commands).
TODO: TODO:
- implement it correctly * implement it correctly
- finish asynchronous commands (especially for reading/record) * finish asynchronous commands (especially for reading/record)
- better implement non waiting command (without the MCI_WAIT * better implement non waiting command (without the MCI_WAIT flag).
flag).
2.3.2 Native
2.3.2 Native
Native MCIMIDI has been working but is currently blocked by scheduling
Native MCIMIDI has been working but is currently blocked by issues (mmTaskXXX no longer work).
scheduling issues (mmTaskXXX no longer work).
FIXME:
* midiStreamPlay get from time to time an incorrect MidiHdr when
using the native MCI sequencer
2.4 MCIANIM 2.4 MCIANIM
----------- -----------
2.4.1 Builtin 2.4.1 Built-in
The implementation consists of stubs and is in The implementation consists of stubs and is in dlls/winmm/mcianim.c.
multimedia/mcianim.c.
TODO:
TODO: * implement it, probably using xanim or something similar.
- implement it, probably using xanim or something similair.
2.4.2 Native
2.4.2 Native
Native MCIANIM is reported to work (but requires native video DLLs
Native MCIANIM is reported to work (but requires native video DLLs
also). also).
2.5 MCIAVI 2.5 MCIAVI
---------- ----------
2.5.1 Builtin 2.5.1 Built-in
The implementation consists of stubs and is in multimedia/mciavi.c. The implementation consists of stubs and is in
dlls/winmm/mciavi/mciavi.c.
TODO:
- implement it, probably using xanim or something similair. TODO:
* implement it, probably using xanim or something similar.
2.5.2 Native 2.5.2 Native
Native MCIAVI is reported to work (but requires native video DLLs Native MCIAVI is reported to work (but requires native video DLLs
also). Some files exhibit some deadlock issues anyway. also). Some files exhibit some deadlock issues anyway.
3 High-level layers 3 High level layers
=================== ===================
The rest (basically the MMSYSTEM and WINMM DLLs entry points). The rest (basically the MMSYSTEM and WINMM DLLs entry points). It also
It also provides the skeletton for the core functionnalites for provides the skeleton for the core functionality for multimedia
multimedia rendering. rendering. Note that native MMSYSTEM and WINMM do not currently work
under WINE and there is no plan to support them (it would require to
Note that native mmsystem and WINMM do not currently under WINE also fully support VxD, which is not done yet).
and there is no plan to support them (it would require to also MCI and low level drivers can either be 16 or 32 bit.
fully support VxD, which is not done yet).
TODO: TODO:
- allow a dynamic loading of low level driver (should have one * it seems that some program check what's installed in registry
for OSS, another one for ALSA...) against value returned by drivers. Wine is currently broken
- add clean-up mechanisms when process detach from MM DLLs regarding this point.
- reimplement the sndPlay??? functions using MCI commands * add clean-up mechanisms when process detaches from MM DLLs
rather than rewriting everything from scratch. * prepare for the 16/32 big split
- prepare for the 16/32 bit split * check thread-safeness for MMSYSTEM and WINMM entry points
- check thread-safeness for MMSYSTEM and WINMM entry points * unicode entry points are badly supported
3.1 MCI skeletton 3.1 MCI skeleton
----------------- ----------------
Implementation of what is needed to load/unload MCI drivers, and
to pass correct information to them. This is implemented in
multimedia/mci.c and multimedia/mcistring.c
The mciSendString function uses commandstrings, which are
translated into normal MCI commands as used by mciSendCommand.
The API can be found in multimedia/mmsystem.c and
multimedia/mcistring.c. The functions there (mciOpen,mciSysInfo)
handle midlevel driver allocation and calls.
The implementation is not complete.
MCI drivers are seen as regular WINE modules, and can be loaded
(with a correct loadorder between builtin, native, elfdll, so), as
any other DLL. Please note, that MCI drivers module names must
bear the .drv extension to be correctly understood.
Implementation of what is needed to load/unload MCI drivers, and to
pass correct information to them. This is implemented in
dlls/winmm/mci.c. The mciSendString function uses command strings,
which are translated into normal MCI commands as used by
mciSendCommand with the help of command tables. The API can be found
in dlls/winmm/mmsystem.c and dlls/winmm/mci.c. The functions there
(mciOpen,mciSysInfo) handle mid level driver allocation and calls. The
implementation is not complete.
MCI drivers are seen as regular WINE modules, and can be loaded (with
a correct load order between built-in, native, elfdll, so), as any
other DLL. Please note, that MCI drivers module names must bear the
.drv extension to be correctly understood.
The list of available MCI drivers is obtained as follows: The list of available MCI drivers is obtained as follows:
1/ key 'mci' in [option] section from .winerc (or wineconf) 1. key 'mci' in [option] section from .winerc (or wineconf)
mci=CDAUDIO:SEQUENCER mci=CDAUDIO:SEQUENCER gives the list of MCI drivers (names, in
gives the list of MCI drivers (names, in uppercase only) to uppercase only) to be used in WINE.
be used in WINE. 2. This list, when defined, supersedes the mci key in
2/ This list, when defined, supercedes the mci c:\windows\system.ini
key in c:\windows\system.ini
Note that native VIDEODISC crashes when the module is loaded, which
occurs when the MCI procedures are initialised. Make sure that this is
not in the list from above. Try adding:
mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
to the [options] section of wine.conf.
TODO: TODO:
- MCI command loading support mci(Load|Free)Command * correctly handle the MCI_ALL_DEVICE_ID in functions.
- implement other stuff as yet unknown * finish mapping 16 <=> 32 of MCI structures and commands
- in mciString(), make use of hiword from mciSendMessage * MCI_SOUND is not handled correctly (should not be sent to MCI
return value to convert value into string... driver => same behavior as MCI_BREAK)
- mmTaskXXX functions are currently broken because the 16 * do not display module warning when failed to 32-bit load a 16 bit
loader does not support binary command lines. module when 16 bit load can succeed (and the other way around)
* implement auto-open feature (ie, when a string command is issued
for a not yet opened device, MCI automatically opens it)
3.2 MCI multi-tasking 3.2 MCI multi-tasking
--------------------- ---------------------
Multi-tasking capabilities used for the MCI drivers are provided
in multimedia/mmsystem.c
Multi-tasking capabilities used for the MCI drivers are provided in
dlls/winmm/mmsystem.c.
TODO:
mmTaskXXX functions are currently broken because the 16 loader does
not support binary command lines => provide Wine's own mmtask.tsk not
using binary command line.
the Wine native MCI drivers should use the mmThreadXXX API and no
longer use the MCI_AsyncCommand hack.
3.3 Timers 3.3 Timers
---------- ----------
It currently uses a service thread, run in the context of the calling It currently uses a service thread, run in the context of the calling
process, which should correctly mimic Windows behaviour. process, which should correctly mimic Windows behavior.
TODO: TODO:
- Check if minimal time is satisfactory for most programs. * Check if minimal time is satisfactory for most programs.
* current implementation may let a timer tick (once) after it has
been destroyed
3.4 MMIO 3.4 MMIO
-------- --------
The API consists of the mmio* functions found in mdlls/winmm/mmio.c.
Seems to work ok in most of the cases. There's some linear/segmented
issues with 16 bit code.
The API consists of the mmio* functions found in multimedia/mmio.c. 3.5 sndPlayXXX functions
------------------------
Seems to work ok in most of the cases. Seem to work correctly.
4 Multimedia configuration
==========================
Currently, multimedia configuration heavily relies on Win 3.x
configuration model.
4.1 Drivers
-----------
Since all multimedia drivers (MCI, low level ones, ACM drivers,
mappers) are, at first, drivers they need to appear in the [mci] or
[mci32] section of the system.ini file.
Since all drivers are, at first, DLLs, you can choose to load their
Wine's (builtin) or Windows (native) version.
4.2 MCI
-------
A default [mci] section (in system.ini) looks like (see the note above
on videodisc):
[mci]
cdaudio=mcicda.drv
sequencer=mciseq.drv
waveaudio=mciwave.drv
avivideo=mciavi.drv
videodisc=mcipionr.drv
vcr=mcivisca.drv
MPEGVideo=mciqtz.drv
By default, the list of loadable MCI drivers will be made of those
drivers (in the [mci] section).
The list of loadable (recognized) MCI drivers can be altered in the
[option] section of wine.conf, like:
mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
TODO: TODO:
- ...
use a default registry setting to bypass this (ugly) configuration
model
4.3 Low level drivers
---------------------
@------------------------------------@ They are currently hardcoded in dlls/winmm/lolvldrv.c.
@ Last updated: 12, May 1999 @
@ Eric Pouech <eric.pouech@lemel.fr> @ TODO:
@------------------------------------@
use a default registry setting to provide a decent configuration
model. this shall also help some programs to work (some of them test
the names returned by low level drivers with the ones defined and
installed in the registry)
4.4 ACM
-------
To be done (use the same mechanism as MCI drivers configuration).
5 Multimedia architecture
=========================
5.1 Windows 9x multimedia architecture
--------------------------------------
|
Kernel space | Client applications
|
| | | ^ ^ | | | |
| 16>| |<32 16>| |<32 16>| |<32 16>| |<32
| | v | | | v | v
| +----|-----------|---------|------------|-------+
| | | | | | | WinMM.dll
| | | | | | | 32 bit
| +----|-----------|---------|------------|-------+
| | | | ^ | | |
| +------+ | |<16 | | | |<16 |
| | 16>| | | | | | | |
| | v v v | | v v v
| | +---------------+---+-------------+-------------+
| | | waveInXXX | | mciXXX | *playSound* |
| | | waveOutXXX | | | mmioXXX |
| | | midiInXXX | | | timeXXX |
| | | midiOutXXX | | | driverXXX |
| | | midiStreamXXX | | | | MMSystem.dll
| | | mixerXXX | | | | 16 bit
+--------+ | | | auxXXX +---+ +---+ mmThread| |
|MMDEVLDR|<------->| joyXXX | Call back | mmTask | |
+--------+ | | +-----------+-----------+---------+-------------+
^ | | | ^ ^ | ^
| | | 16>| |<16>| 16>| |<16
v | | v | | v |
+--------+ | | +-------------+ +----------+
| VxD |<------->| .drv | | mci*.drv |
+--------+ | | +--------------+ +-----------+
| | | msacmm.drv | | mciwave |
| | +--------------+ +-----------+
| | | midimap.drv | | mcimidi |
| | +-------------+ +-----------+
| | Low-level drivers | ... | MCI drivers
| | +----------+
| | |
| | |<16
| +-------------------------------+
|
The important points to notice are:
* all drivers (and most of the core code) is 16 bit
* all hardware (or most of it) dependant code reside in the kernel
space (which is not surprising)
5.2 Wine multimedia architecture
--------------------------------
|
Kernel space | Client applications
|
| | | ^ ^ | | | |
| 16>| |<32 16>| |<32 16>| |<32 16>| |<32
| | | | | | | | |
| +------+ | | | | | | | |
| |32/16>| | | | | | | | |
| | v v v | | v v v v
| | +---------------+---+-------------+-------------+
| | | waveInXXX | | mciXXX | *playSound* |
| | | waveOutXXX | | | mmioXXX | WinMM.dll
| | | midiInXXX | | | timeXXX | 32 bit
| | | midiOutXXX | | | driverXXX |
| | | midiStreamXXX | | | | MSystem.dll
| | | mixerXXX | | | | 16 bit
| | | auxXXX +---+ +---+ mmThread| |
| | | joyXXX | Call back | mmTask | |
| | +-----------+-----------+---------+-------------+
| | | | ^ ^ || ^^
| | 16>| |<32 |<16>| 16>||<32>||<16
| | v v |<32>| vv ||
+---------+ | | +-------------+ +----------+
|HW driver|<------->| .drv | | mci*.drv |
+---------+ | | +--------------+ +-----------+
| | | msacmm.drv | | mciwave |
| | +--------------+ +-----------+
| | | midimap.drv | | mcimidi |
| | +-------------+ +-----------+
| | Low-level drivers | ... | MCI drivers
| | +----------+
| | |
| | |<32/16
| +-------------------------------+
|
From the previous drawings, the most noticeable difference are:
* low-level drivers can either be 16 or 32 bit
* MCI drivers can either be 16 or 32 bit
* MMSystem and WinMM will be hosted in a single elfglue library
* no link between the MMSystem/WinMM pair on kernel space shall
exist. For example, there will be a low level driver to talk to a
UNIX OSS (Open Sound System) driver
* all built-in drivers (low-level and MCI) will be written as 32 bit
drivers
all native drivers will be 16 bits drivers
______________________________________________________
Last updated: 6, December 1999
By: Eric Pouech (eric.pouech@wanadoo.fr)
References
1. http://www.4front-tech.com/