Skip to content

W
wine-cw
Commit 1876d185 authored by Eric Pouech's avatar Eric Pouech Committed by Alexandre Julliard
Browse files
Options

- bring the multimedia doc up-to-date

- moved the TODO from the doc into the code
parent c3cecc5d
Show whitespace changes
Inline Side-by-side
Showing with 769 additions and 955 deletions
dlls/winmm/mciseq/mcimidi.c
View file @ 1876d185
......@@ -29,6 +29,13 @@
* 98/11 splitted in midi.c and mcimidi.c
*/
/* TODO:
* + implement it correctly
* + finish asynchronous commands (especially for reading/record)
* + better implement non waiting command (without the MCI_WAIT flag).
* + implement the recording features
*/
#include <stdlib.h>
#include <stdarg.h>
#include <stdio.h>
......
dlls/winmm/wineoss/midi.c
View file @ 1876d185
......@@ -26,6 +26,19 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
/* TODO:
* + use better instrument definition for OPL/2 (midiPatch.c) or
* use existing instrument definition (from playmidi or kmid)
* with a .winerc option
* + have a look at OPL/3 ?
* + implement asynchronous playback of MidiHdr
* + implement STREAM'ed MidiHdr (question: how shall we share the
* code between the midiStream functions in MMSYSTEM/WINMM and
* the code for the low level driver)
* + use a more accurate read mechanism than the one of snooping on
* timers (like select on fd)
*/
#include "config.h"
#include <string.h>
......
dlls/winmm/wineoss/mixer.c
View file @ 1876d185
......@@ -21,6 +21,10 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
/* TODO:
* + implement notification mechanism when state of mixer's controls
*/
#include "config.h"
#include <stdlib.h>
......
dlls/winmm/winmm.c
View file @ 1876d185
......@@ -28,6 +28,17 @@
* 99/9 added support for loadable low level drivers
*/
/* TODO
* + it seems that some programs check what's installed in
* registry against the value returned by drivers. Wine is
* currently broken regarding this point.
* + check thread-safeness for MMSYSTEM and WINMM entry points
* + unicode entry points are badly supported (would require
* moving 32 bit drivers as Unicode as they are supposed to be)
* + allow joystick and timer external calls as we do for wave,
* midi, mixer and aux
*/
#include <stdio.h>
#include <stdarg.h>
#include <string.h>
......
documentation/multimedia.sgml
View file @ 1876d185
......@@ -7,10 +7,12 @@
</para>
<para>
The implementation can be found in the dlls/winmm/ directory (and in
many of its subdirectories), but also in dlls/msacm/ (for the
audio compression/decompression manager) and dlls/msvideo/ (for the
video compression/decompression manager).
The implementation can be found in the
<filename>dlls/winmm/</filename> directory (and in many of its
subdirectories), but also in <filename>dlls/msacm/</filename>
(for the audio compression/decompression manager) and
<filename>dlls/msvideo/</filename> (for the video
compression/decompression manager).
</para>
<sect1 id="mm-overview">
......@@ -24,925 +26,941 @@
</para>
<para>
The low level layer may depend on current hardware and OS services
(like OSS on Unix). Mid level (MCI) and high level layers must be
written independently from the hardware and OS services.
All of those components are defined as DLLs (one by one).
</para>
<para>
There are two specific low level drivers (msacm.drv for wave input/output,
midimap.drv for MIDI output only), whose role is:
<itemizedlist>
<listitem>
<para>
help choosing one low level driver between many
</para>
</listitem>
<listitem>
<para>
add the possibility to convert streams (ie ADPCM =&gt;
PCM) (this is useful if the format required by the
application for playback isn't supported by the soundcard).
The low level layer may depend on current hardware and OS services
(like OSS on Unix). It provides the core of playback/record
using fine grain objects (audio/midi streams...).
</para>
</listitem>
<listitem>
<para>
add the possibility to filter a stream (adding echo, equalizer...
to a wave stream), or modify the instruments that have to be
played (MIDI).
</para>
</listitem>
</itemizedlist>
Mid level (MCI) and high level layers must be written independently from
the hardware and OS services.
</para>
<para>
All of those components are defined as DLLs (one by one).
MCI level provides some coarser grain operations (like playing
a Midi file, or playing a video stream).
</para>
</sect1>
<sect1 id="mm-low">
<title>Low level layers</title>
<para>
Please note that native low level drivers are not currently supported
in Wine, because they either access hardware components or require
VxDs to be loaded; Wine does not correctly supports those two so far.
</para>
<para>
The following low level layers are implemented (as built-in DLLs):
</para>
<sect1 id="mm-arch">
<title>Multimedia architecture</title>
<sect2>
<title>(Wave form) Audio</title>
<para>
MMSYSTEM and WINMM call the real low level audio driver using the
wodMessage/widMessage which handles the different requests.
</para>
<sect3>
<title>OSS implementation</title>
<para>
The low level audio driver is currently only implemented for the
OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by
<ulink url="http://www.4front-tech.com/">4Front Technologies</ulink>.
The presence of this driver is checked by configure (depends on the
&lt;sys/soundcard.h&gt; file). Source code resides in
dlls/winmm/wineoss/audio.c.
</para>
<title>Windows 95 multimedia architecture</title>
<para>
The implementation contains all features commonly used, but has
several problems (see TODO list).
</para>
<screen>
|
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 |
+--------+ | | +--------------+ +-----------+
| | | msacm.drv | | mciwave |
| | +--------------+ +-----------+
| | | midimap.drv | | mcimidi |
| | +-------------+ +-----------+
| | Low-level drivers | ... | MCI drivers
| | +----------+
| | |
| | |<16
| +-------------------------------+
|
</screen>
<para>
Note that some Wine specific flag has been added to the wodOpen function,
so that the dsound DLL can share the /dev/dsp access. Currently, this
only provides mutual exclusion for both DLLs. Future extension could add
a virtual mixer between the two output streams.
</para>
<para>TODO:
The important points to notice are:
<itemizedlist>
<listitem>
<para>
verify all functions for correctness
all drivers (and most of the core code) is 16 bit
</para>
</listitem>
<listitem>
<para>
Add virtual mixer between wave-out and dsound interfaces.
all hardware (or most of it) dependent code reside in the kernel
space (which is not surprising)
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
<sect3>
<title>Other sub systems</title>
<para>
Support is also provided for ALSA, aRts, NAS, Jack,
AudioIO, but with less intensive debugging than the OSS.
</para>
<para>
EsounD isn't supported yet. ALSA support still needs a
couple of refinements.
</para>
</sect3>
</sect2>
<sect2>
<title>MIDI</title>
<title>Windows NT multimedia architecture</title>
<para>
MMSYSTEM and WINMM call the low level driver functions using the
midMessage and the modMessage functions.
</para>
<sect3>
<title>OSS driver</title>
<para>
The low level audio driver is currently only implemented for the
OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by
<ulink url="http://www.4front-tech.com/">4Front Technologies</ulink>.
The presence of this driver is checked by configure (depends on the
&lt;sys/soundcard.h&gt; file, and also some specific defines because
MIDI is not supported on all OSes by OSS). Source code resides in
dlls/winmm/wineoss/midi.c
Note that Win 98 has mixed 95/NT architecture, so when
speaking about Windows 95 (resp. NT) architecture, it refers
to the type of architecture, not what's actually
implemented. For example, Windows 98 implements both types
of architectures.
</para>
<para>
Both Midi in and Midi out are provided. The type of MIDI devices
supported is external MIDI port (requires a MIDI capable device -
keyboard...) and OPL/2 synthesis (the OPL/2 patches for all
instruments are in midiPatch.c).
</para>
<para>TODO:
The important points to notice (compared to the Windows 95
architecture) are:
<itemizedlist>
<listitem>
<para>
use better instrument definition for OPL/2 (midiPatch.c) or use
existing instrument definition (from playmidi or kmid) with a
.winerc option
drivers (low level, MCIs...) are 32 bit and Unicode
</para>
</listitem>
<listitem>
<para>
have a look at OPL/3 ?
the interfaces between kernel and user drivers has
changed, but it doesn't impact much Wine. Those
changes allow some good things (like kernel mixing,
where different apps share the audio hardware) and of
course bad things (like kernel mixing, which adds
latency).
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Wine multimedia architecture</title>
<screen>
|
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 | | | | MMSystem.dll
| | | mixerXXX | | | | 16 bit
| | | auxXXX +---+ +---+ mmThread| |
| | | joyXXX | Call back | mmTask | |
| | +-----------+-----------+---------+-------------+
| | || ^ ^ | ^
| | 16>||<32 |<16>| 16>| |<16
| | vv |<32>| 32>v |<32
+---------+ | | +-------------+ +----------+
|HW driver|<------->| *.drv | | mci*.drv |
+---------+ | | +--------------+ +-----------+
| | | msacm.drv | | mciwave |
| | +--------------+ +-----------+
| | | midimap.drv | | mcimidi |
| | +-------------+ +-----------+
| | Low-level drivers | ... | MCI drivers
| | +----------+
| | |
| | |<32/16
| +-------------------------------+
|
</screen>
<para>
From the previous drawings, the most noticeable differences are:
<itemizedlist>
<listitem>
<para>
implement asynchronous playback of MidiHdr
low-level drivers can either be 16 or 32 bit (in fact,
Wine supports only native wave and audio mappers).
</para>
</listitem>
<listitem>
<para>
implement STREAM'ed MidiHdr (question: how shall we share the code
between the midiStream functions in MMSYSTEM/WINMM and the code
for the low level driver)
MCI drivers can either be 16 or 32 bit
</para>
</listitem>
<listitem>
<para>
use a more accurate read mechanism than the one of snooping on
timers (like select on fd)
all built-in drivers (low-level and MCI) will be written as 32 bit
drivers
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
<sect3>
<title>Other sub systems</title>
<para>
Could support other MIDI implementation for other sub
systems (ALSA, any other idea here ?)
</para>
<para>
Could also implement a software synthesizer, either inside Wine or
using using MIDI loop back devices in an external program (like
timidity). The only trouble is that timidity is GPL'ed...
Note: this could be achieved using the ALSA sequencer and
Timidity being used as a server.
Wine's WinMM automatically adapts the messages to be sent to
a driver so that it can convert it to 16 or 32 bit
interfaces.
</para>
</sect3>
</sect2>
<sect2>
<title>Mixer</title>
</sect1>
<sect1 id="mm-low">
<title>Low level layers</title>
<para>
MMSYSTEM and WINMM call the low level driver functions using the
mxdMessage function.
The low level drivers abstract the hardware specific features
from the rest of the multimedia code. Those are implemented with a
well defined set of APIs, as windows do.
</para>
<sect3>
<title>OSS implementation</title>
<para>
The current implementation uses the OpenSoundSystem mixer, and resides
in dlls/winmm/wineoss/mixer.c
Please note that native low level drivers are not currently supported
in Wine, because they either access hardware components or require
VxDs to be loaded; Wine does not correctly supports those two so far.
</para>
<para>TODO:
<para>
There are two specific low level drivers (msacm.drv for wave input/output,
midimap.drv for MIDI output only). These drivers (also present
in Windows) allow:
<itemizedlist>
<listitem>
<para>
implement notification mechanism when state of mixer's controls
change
choosing one low level driver between many (we'll
discuss how the choice is made later on)
</para>
</listitem>
</itemizedlist>
<listitem>
<para>
add the possibility to convert stream's format (ie ADPCM =&gt;
PCM) (this is useful if the format required by the
application for playback isn't supported by the soundcard).
</para>
</sect3>
<sect3>
<title>Other sub systems</title>
<para>TODO:
<itemizedlist>
</listitem>
<listitem>
<para>
implement mixing low level drivers for other mixers (ALSA...)
add the possibility to filter a stream (adding echo, equalizer...
to a wave stream, or modify the instruments that have to be
played for a MIDI stream).
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
</sect2>
<sect2>
<title>Aux</title>
<title>Hardware-bound low level drivers</title>
<para>
The AUX low level driver is the predecessor of the mixer driver
(introduced in Win 95).
</para>
<sect3>
<title>OSS driver</title>
Each low lever driver has to implement at least one of the
following functionality, through the named function:
<itemizedlist>
<listitem>
<para>
The implementation uses the OSS mixer API, and is incomplete.
Waveform audio: out for playback, and in for
recording. MMSYSTEM and WINMM call the real low level
audio driver using the driver's
<function>wodMessage</function> and
<function>widMessage</function> functions which handle
the different requests.
</para>
<para>TODO:
<itemizedlist>
</listitem>
<listitem>
<para>
verify the implementation
MIDI (Musical Instrument Digital Interface): out for
playback, and in for recording. MMSYSTEM and WINMM
call the low level driver functions using the driver's
<function>midMessage</function> and the
<function>modMessage</function> functions.
</para>
</listitem>
<listitem>
<para>
check with what is done in mixer
Mixer: this allows setting the volume for each one of
the other functionnality (and also some specific
attributes, like left/right balance for stereo
streams...). MMSYSTEM and WINMM call the low level
driver functions using the
<function>mxdMessage</function> function.
</para>
</listitem>
<listitem>
<para>
open question: shall we implement it on top of the low level mixer
functions ?
Aux: this is the predecessor of the mixer
functionnality (introduced in Win 95). Its usage has
been deprecated in favor of mixer interfaces.
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
</sect2>
<sect2>
<title>Wine OSS</title>
<para>
All the OSS dependent functions are stored into the WineOSS DLL. It still
lack a correct installation scheme (as any multimedia device under Windows),
so that all the correct keys are created in the registry. This requires
an advanced model since, for example, the number of wave out devices can
only be known on the destination system (depends on the sound card driven
by the OSS interface). A solution would be to install all the multimedia
drivers through the SETUPX DLL; this is not doable yet (the multimedia
extension to SETUPX isn't written yet).
Wine currently supports the following (kernel) multimedia
interfaces.
<itemizedlist>
<listitem>
<para>
Open Sound System (OSS) as supplied in the Linux and
FreeBSD kernels by <ulink
url="http://www.4front-tech.com/">4Front
Technologies</ulink>. The presence of this driver is
checked by configure (depends on the
&lt;sys/soundcard.h&gt; file). Source code resides in
<filename>dlls/winmm/wineoss</filename>.
</para>
</sect2>
<sect2>
<title>Joystick</title>
</listitem>
<listitem>
<para>
The API consists of the joy* functions found in dlls/winmm/joystick/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.
Advanced Linux Sound Architecture (<ulink
url="http://www.alsa-project.org/">ALSA</ulink>) as
supplied in the Linux kernel. Source code resides in
<filename>dlls/winmm/winealsa</filename>.
</para>
<para>TODO:
<itemizedlist>
</listitem>
<listitem>
<para>
Analog RealTime Synthetizer (<ulink
url="http://www.arts-project.org/">aRts</ulink>): a
network server (and virtual mixer) used in the KDE project.
</para>
</listitem>
<listitem>
<para>
better support of enhanced joysticks (Linux 2.2 interface is available)
Network Audio Server (<ulink
url="http://radscan.com/nas.html">NAS</ulink>): an
audio server.
</para>
</listitem>
<listitem>
<para>
support more joystick drivers (like the XInput extension)
<ulink
url="http://jackit.sourceforge.net/">Jack</ulink>: a
low latency audio server.
</para>
</listitem>
<listitem>
<para>
should load joystick DLL as any other driver (instead of hardcoding)
the driver's name, and load it as any low lever driver.
AudioIO: the native Solaris audio interface.
</para>
</listitem>
</itemizedlist>
</para>
<para>
The supported functionnalities per driver is as follows
(this table lists the available features of the products,
not exactly what's actually implemented on Wine):
<table frame="all">
<title>Wine multimedia drivers' functionalities</title>
<tgroup cols="6" align="left" colsep="1" rowsep="1">
<thead>
<row>
<entry>Driver</entry>
<entry>Wave Out</entry>
<entry>Wave In</entry>
<entry>Midi Out</entry>
<entry>Midi In</entry>
<entry>Mixer (and Aux)</entry>
</row>
</thead>
<tbody>
<row>
<entry>OSS</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry>ALSA</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry>aRts</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>Yes</entry>
</row>
<row>
<entry>NAS</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>Yes</entry>
</row>
<row>
<entry>AudioIO</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>Yes</entry>
</row>
<row>
<entry>Jack</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>Yes</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
<para>
Lots of listed drivers won't support Midi (in a short time)
because the exposed "Un*x" native interfaces don't. This
would require using some kind as software synthesis (as
Timidity), but we cannot incorporate as it's GPL'ed.
</para>
</sect2>
<sect2>
<title>Wave mapper (msacm.drv)</title>
<para>
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 Wave mapper device allows to load on-demand audio 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 in MSACM32.DLL.
</para>
<sect3>
<title>Built-in</title>
<para>
A first working implementation for wave out as been provided (wave in
exists, but doesn't allow conversion).
Wave mapper driver implementation can be found in
<filename>dlls/winmm/wavemap/</filename> directory. This
driver heavily relies on MSACM and MSACM32 DLLs which can be
found in <filename>dlls/msacm</filename> and
<filename>dlls/msacm32</filename>. Those DLLs load ACM
drivers which provide the conversion to PCM format (which is
normally supported by low level drivers). A Law, uLaw,
ADPCM, MP3... fit into the category of non PCM formats.
</para>
<para>
Wave mapper driver implementation can be found in dlls/winmm/wavemap/
directory. This driver heavily relies on MSACM and MSACM32 DLLs which
can be found in dlls/msacm and dlls/msacm32. Those DLLs load ACM
drivers which provide the conversion to PCM format (which is normally
supported by low level drivers). ADPCM, MP3... fit into the category
of non PCM formats.
</para>
</sect2>
<sect2>
<title>MIDI mapper (midimap.drv)</title>
<para>
There is currently no built-in ACM driver in Wine, so you must use
native ones if you're looking for non PCM playback.
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 definitions
(XM, GM...). It also permits to output on a per channel
basis to different MIDI renderers.
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
check for correctness and robustness
</para>
</listitem>
</itemizedlist>
A built-in MIDI mapper can be found in
<filename>dlls/winmm/midimap/</filename>. It partly provides
the same functionality as the Windows' one. It allows to
pick up destination channels: you can map a given channel to
a specific playback device channel (see the configuration
bits for more details).
</para>
</sect3>
<sect3>
<title>Native</title>
</sect2>
</sect1>
<sect1 id="mm-mci">
<title>Mid level drivers (MCI)</title>
<para>
Seems to work quite ok (using of course native MSACM/MSACM32 DLLs)
Some other testings report some issues while reading back the registry
settings.
The mid level drivers are represented by some common API
functions, mostly <function>mciSendCommand</function> and
<function>mciSendString</function>. Wine implements several
MCI mid level drivers.
</para>
<para>
<table frame="all">
<title>Wine MCI drivers</title>
<tgroup cols="4" align="left" colsep="1" rowsep="1">
<thead>
<row>
<entry>MCI Name</entry>
<entry>DLL Name</entry>
<entry>Role</entry>
<entry>Location</entry>
<entry>Comments</entry>
</row>
</thead>
<tbody>
<row>
<entry>CdAudio</entry>
<entry>MciCDA.drv</entry>
<entry>MCI interface to a CD audio player</entry>
<entry><filename>dlls/winmm/mcicda/</filename></entry>
<entry>
Relies on NTDLL CdRom raw interface (through
<function>DeviceIoControl</function>).
</entry>
</row>
<row>
<entry>WaveAudio</entry>
<entry>MciWave.drv</entry>
<entry>
MCI interface for wave playback and record
</entry>
<entry><filename>dlls/winmm/mciwave/</filename></entry>
<entry>It uses the low level audio API.</entry>
</row>
<row>
<entry>Sequencer</entry>
<entry>MciSeq.drv</entry>
<entry>Midi Sequencer (playback)</entry>
<entry><filename>dlls/winmm/mciseq/</filename></entry>
<entry>It uses the low level midi APIs</entry>
</row>
<row>
<entry>AviVideo</entry>
<entry>MciAvi.drv</entry>
<entry>AVI playback and record</entry>
<entry><filename>dlls/winmm/mciavi/</filename></entry>
<entry>
It rather heavily relies on MSVIDEO/MSVFW32 DLLs
pair to work.
</entry>
</row>
</tbody>
</tgroup>
</table>
The MCI Name column is the name of the MCI driver, as it is
searched in configuration. The DLL Name column is the name of
the DLL the configuration provides as a value. The name listed
here is the default one (see the configuration section for the
details).
</para>
<para>
Adding a new MCI driver is just a matter of writing the
corresponding DLL with the correct interface (see existing MCI
drivers for the details), and to provide the relevant setup
information for <filename>wine.inf</filename>
</para>
</sect3>
</sect1>
</sect2>
<sect1 id="mm-high">
<title>High level layers</title>
<sect2>
<title>MIDI mapper</title>
<para>
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.
</para>
<sect3>
<title>Built-in</title>
<title>WINMM (and MMSYSTEM)</title>
<para>
A built-in MIDI mapper can be found in dlls/winmm/midimap/. It partly
provides the same functionality as the Windows' one. It allows to pick up
destination channels (you can map a given channel to a specific playback
device channel (see the configuration bits for more details).
The high level layers encompass basically the MMSYSTEM and
WINMM DLLs exported APIs. It also provides the skeleton for
the core functionality for multimedia playback and
recording. Note that native MMSYSTEM and WINMM do not
currently work under Wine and there is no plan to support
them (it would require to also fully support VxD, which is
not done yet).
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
implement the Midi mapper features (instrument on the fly modification)
if it has to be done as under Windows, it required parsing the midi
configuration files (didn't find yet the specs)
</para>
</listitem>
</itemizedlist>
WINMM and MMSYSTEM in Wine can handle both 16 bit and 32 bit
drivers (for low level and MCI drivers). It will handle all
the conversions transparently for the all the calls to WINMM
and MMSYSTEM, as it knows what the driver interface is (16
bit or 32 bit) and it manages the information sent
accordingly.
</para>
</sect3>
<sect3>
<title>Native</title>
<para>
The native midimapper from Win 98 works, but it requires a bunch of
keys in the registry which are not part of the Wine source yet.
MCI drivers are seen as regular Wine modules, and can be
loaded (with a correct load order between builtin, native),
as any other DLL. Please note, that MCI drivers module names
must bear the <filename>.drv</filename> extension to be
correctly understood.
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
add native midimapper keys to the registry to let it run. This
will require proper multimedia driver installation routines.
</para>
</listitem>
</itemizedlist>
Multimedia timers are implemented with a dedicated thread,
run in the context of the calling process, which should
correctly mimic Windows behavior. The only drawback is that
the thread will appear the calling process if it enumerates
the running processes.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="mm-mci">
<title>Mid level drivers (MCI)</title>
<para>
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):
</para>
<para>TODO: (apply to all built-in MCI drivers)
<itemizedlist>
<listitem>
<para>
use MMSYSTEM multitasking caps instead of the home grown
</para>
</listitem>
</itemizedlist>
</para>
<sect2>
<title>CDAUDIO</title>
<sect3>
<title>Built-in</title>
<para>
The currently best implementation is the MCI CDAUDIO driver that can
be found in dlls/winmm/mcicda/mcicda.c. The implementation is mostly
complete, there have been no reports of errors. It makes use of
dlls/ntdll/cdrom.c Wine cdrom interface.
This interface has been ported on Linux, FreeBSD and NetBSD. (Sun
should be similar, but are not implemented.)
</para>
<para>
A very small example of a cdplayer consists just of the line
mciSendString("play cdaudio",NULL,0,0);
</para>
<title>DSOUND</title>
<para>TODO:
<itemizedlist>
<listitem>
<para>
add support for other cdaudio drivers (Solaris...)
</para>
</listitem>
<listitem>
<para>
add support for multiple cdaudio devices (plus a decent
configuration scheme)
</para>
</listitem>
</itemizedlist>
Wine also provide a DSound (DirectX) DLL with the proper
COM implementation.
</para>
</sect3>
<sect3>
<title>Native</title>
<para>
Native MCICDA works also correctly... It uses the MSCDEX traps (on int
2f). However, some commands (like seeking) seem to be broken.
Note that a Wine specific flag has been added to the
<function>wodOpen</function> function, so that the DSound
DLL can get a reference to a COM sound object from a given
WINMM wave output device. This should be changed in the
future.
</para>
</sect3>
</sect2>
<sect2>
<title>MCIWAVE</title>
<sect3>
<title>Built-in</title>
<para>
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).
</para>
<para>FIXME:
<itemizedlist>
<listitem>
<para>
The MCI_STATUS command is broken.
</para>
</listitem>
</itemizedlist>
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
check for correctness
</para>
</listitem>
<listitem>
<para>
better use of asynchronous playback from low level
</para>
</listitem>
<listitem>
<para>
better implement non waiting command (without the MCI_WAIT flag).
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
</sect3>
<sect1 id="msacm">
<title>MS ACM Dlls</title>
<sect3>
<title>Native</title>
<sect2>
<title>Contents</title>
<para>
Native MCIWAVE works also correctly.
The MSACM32 (and its 16 bit sibbling MSACM) provide a way to
map a given wave format to another format. It also provides
filtering capabilities. Those DLLs only implement the proper
switch between a caller and a driver providing the
implementation of the requested format change or filter
operation.
</para>
<para>
There's nothing specific in Wine's implementation compared
to Windows' one. Here's however a list of the builtin format
change drivers (there's no filter driver yet):
<table frame="all">
<title>Wine ACM drivers</title>
<tgroup cols="2" align="left" colsep="1" rowsep="1">
<thead>
<row>
<entry>Name</entry>
<entry>Provides</entry>
</row>
</thead>
<tbody>
<row>
<entry>imaadp32</entry>
<entry>IMA ADPCM (adaptative PCM)</entry>
</row>
<row>
<entry>msadp32</entry>
<entry>Microsoft's ADPCM (adaptative PCM)</entry>
</row>
<row>
<entry>msg711</entry>
<entry>Microsoft's G.711 (A-Law and -Law)</entry>
</row>
<row>
<entry>winemp3</entry>
<entry>
Wine's MP3 (MPEG Layer 3), based on mpglib library
</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
<para>
Note that Wine also supports native audio codecs as
well.
</para>
<para>
All builtin ACM drivers are 32 bit Unicode DLLs
</para>
</sect3>
</sect2>
<sect2>
<title>MCISEQ (MIDI sequencer)</title>
<sect3>
<title>Built-in</title>
<title>Caching</title>
<para>
The implementation can be found in dlls/winmm/mciseq/mcimidi.c. Except
for the Record command, should be close to completion (except for non
blocking commands, as many MCI drivers).
</para>
<para>TODO:
The MSACM/MSACM32 keeps some data cached for all known ACM
drivers. Under the key
<screen>
Software\Microsoft\AudioCompressionManager\DriverCache\&lt;driver name&gt;
</screen>
, are kept for values:
<itemizedlist>
<listitem>
<para>
implement it correctly
<literal>aFormatTagCache</literal> which
contains an array of <literal>DWORD</literal>. There
are two <literal>DWORD</literal>s per <literal>cFormatTags</literal>
entry. The first <literal>DWORD</literal> contains a
format tag value, and the second the associated
maximum size for a <literal>WAVEFORMATEX</literal> structure.
(Fields <literal>dwFormatTag</literal> and <literal>cbFormatSize</literal> from
ACMFORMATDETAILS)
</para>
</listitem>
<listitem>
<para>
finish asynchronous commands (especially for reading/record)
<literal>cFilterTags</literal> contains the number of tags supported by the driver
for filtering.
</para>
</listitem>
<listitem>
<para>
better implement non waiting command (without the MCI_WAIT flag).
<literal>cFormatTags</literal> contains the number of tags support
by the driver for conversions.
</para>
</listitem>
<listitem>
<para>
implement the recording features
<literal>fdwSupport</literal> (the same as the one returned from
<function>acmDriverDetails</function>).
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
<sect3>
<title>Native</title>
<para>
Native MCIMIDI has been working but is currently blocked by scheduling
issues (mmTaskXXX no longer work).
</para>
<para>FIXME:
<itemizedlist>
<listitem>
<para>
midiStreamPlay get from time to time an incorrect MidiHdr when
using the native MCI sequencer
</para>
</listitem>
</itemizedlist>
The <literal>cFilterTags</literal>,
<literal>cFormatTags</literal>,
<literal>fdwSupport</literal> are the same values as the
ones returned from <function>acmDriverDetails</function>
function.
</para>
</sect3>
</sect2>
</sect1>
<sect2>
<title>MCIANIM</title>
<sect3>
<title>Built-in</title>
<para>
The implementation is in dlls/winmm/mcianim/.
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
implement it, probably using xanim or something similar.
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
<sect3>
<title>Native</title>
<para>
Native MCIANIM is reported to work (but requires native video DLLs
also, even though the built-in video DLLs start to work correctly).
</para>
</sect3>
</sect2>
<sect1 id="msvfw32">
<title>MS Video Dlls</title>
<sect2>
<title>MCIAVI</title>
<sect3>
<title>Built-in</title>
<title>Contents</title>
<para>
The implementation is in dlls/winmm/mcianim/. Basic features are present,
simple playing is available, even if lots remain to be done. It rather
heavily relies on MSVIDEO/MSVFW32 DLLs pair to work.
The MSVFW32 (and its 16 bit sibbling MSVIDEO) provide
encode/decode video streams. Those DLLs only implement the
proper switch between a caller and a driver providing the
implementation of the requested format coding/decoding
operation.
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
finish the implementation
There's nothing specific in Wine's implementation compared
to Windows' one. Here's however a list of the builtin
decoding drivers:
<table frame="all">
<title>Wine VIDC drivers</title>
<tgroup cols="2" align="left" colsep="1" rowsep="1">
<thead>
<row>
<entry>Name</entry>
<entry>Provides</entry>
</row>
</thead>
<tbody>
<row>
<entry>msrle32</entry>
<entry>Microsoft's RLE (Run-Length encoded)</entry>
</row>
<row>
<entry>msvidc32</entry>
<entry>Microsoft's Video-1</entry>
</row>
<row>
<entry>iccvid</entry>
<entry>Radius Cinepak Video Decoder</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</listitem>
<listitem>
<para>
fix the audio/video synchronization issue
</para>
</listitem>
</itemizedlist>
Note that Wine also supports native video codecs as well.
</para>
</sect3>
<sect3>
<title>Native</title>
<para>
Native MCIAVI is reported to work (but requires native video DLLs
also). Some files exhibit some deadlock issues anyway.
All builtin VIDC drivers are 32 bit Unicode DLLs
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="mm-high">
<title>High level layers</title>
<para>
The rest (basically the MMSYSTEM and WINMM DLLs entry points). It also
provides the skeleton for the core functionality for multimedia
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
also fully support VxD, which is not done yet).
Moreover, native DLLs require 16 bit MCI and low level drivers. Wine
implements them as 32 bit drivers.
MCI and low level drivers can either be 16 or 32 bit for Wine.
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
it seems that some programs check what's installed in registry
against the value returned by drivers. Wine is currently broken
regarding this point.
</para>
</listitem>
<listitem>
<para>
check thread-safeness for MMSYSTEM and WINMM entry points
</para>
</listitem>
<listitem>
<para>
unicode entry points are badly supported
</para>
</listitem>
</itemizedlist>
</para>
<sect2>
<title>MCI skeleton</title>
<para>
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.
</para>
<para>
MCI drivers are seen as regular Wine modules, and can be loaded (with
a correct load order between builtin, native), as any other DLL.
Please note, that MCI drivers module names must bear the .drv
extension to be correctly understood.
</para>
<para>
The list of available MCI drivers is obtained as follows:
1. key 'mci' in [option] section from .winerc (or wineconf)
mci=CDAUDIO:SEQUENCER gives the list of MCI drivers (names, in
uppercase only) to be used in Wine.
2. This list, when defined, supersedes the mci key in
c:\windows\system.ini
</para>
<sect1 id="mm-conf">
<title>Multimedia configuration</title>
<para>
Note that native VIDEODISC crashes when the module is loaded, which
occurs when the MCI procedures are initialized. Make sure that this is
not in the list from above. Try adding:
mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
to the [options] section of the wine config file.
</para>
<para>TODO:
Unfortunately, multimedia configuration evolved over time:
<itemizedlist>
<listitem>
<para>
correctly handle the MCI_ALL_DEVICE_ID in functions.
</para>
</listitem>
<listitem>
<para>
finish mapping 16 <=> 32 of MCI structures and commands
In the early days on Windows 3.x, configuration was
stored in <filename>system.in</filename> file, under
various sections (<literal>[drivers]</literal> for low
level drivers, <literal>[mci]</literal>
(resp. <literal>[mci32]</literal>) for 16 bit (resp. 32
bit) MCI drivers...).
</para>
</listitem>
<listitem>
<para>
MCI_SOUND is not handled correctly (should not be sent to MCI
driver =&gt; same behavior as MCI_BREAK)
With the apparition of the registry, in Windows 95,
configuration as been duplicated there, under the key
<screen>
HKLM\System\CurrentControlSet\Control\MediaResources
</screen>
</para>
</listitem>
<listitem>
<para>
implement auto-open feature (ie, when a string command is issued
for a not yet opened device, MCI automatically opens it)
Windows NT also adopted the registry, but decided to
store the configuration information under another key
than Windows 9x did.
<screen>
HKLM\Software\Microsoft\Windows NT\CurrentVersion
</screen>
And with a different layout of keys and values beneath
this key.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>MCI multi-tasking</title>
<para>
Multi-tasking capabilities used for the MCI drivers are provided in
dlls/winmm/mmsystem.c.
Currently, Wine tries to load first a driver (low-level or
MCI) from the NT registry settings. If it fails, it will try
the <filename>system.ini</filename> configuration.
</para>
<para>
An out-of-the-box configuration is provided in
<filename>wine.inf</filename>, and shall be stored in registry
and <filename>system.ini</filename> at Wine installation
time. It will setup correctly the MCI drivers' configuration
(as well as the wave and MIDI mappers). As the low-level
drivers depend on hardware, their setup will be handled by
<filename>winecfg</filename>.
</para>
<table frame="all">
<title>Wine multimedia configuration scheme</title>
<tgroup cols="5" align="left" colsep="1" rowsep="1">
<thead>
<row>
<entry>Driver</entry>
<entry>Read from NT registry</entry>
<entry>Read from <filename>system.ini</filename></entry>
<entry>Setup by <filename>wine.inf</filename></entry>
<entry>Setup by <filename>winecfg</filename></entry>
</row>
</thead>
<tbody>
<row>
<entry>MCI drivers</entry>
<entry>Yes (1)</entry>
<entry>Yes (2)</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
<row>
<entry>Wave and MIDI mappers</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
<row>
<entry>Hardware-bound low level drivers</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>Yes</entry>
</row>
<row>
<entry>ACM and VIDC drivers (audio & video codecs)</entry>
<entry>No</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
This will allow most settings to be correctly loaded and
handled. However, it won't if an app tries to search directly
the registry for the actual configuration, as the three
potential configuration places may not be in sync.
</para>
<para>
It still lacks a correct installation scheme (as any
multimedia device under Windows), so that all the correct
keys are created in the registry. This requires an advanced
model since, for example, the number of wave out devices can
only be known on the destination system (depends on the
sound card driven by the OSS interface).
</para>
<para>
The following sections describe which type of information
(depending on the location) Wine's multimedia DLLs understand.
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
mmTaskXXX functions are currently broken because the 16 loader does
not support binary command lines =&gt; provide Wine's own mmtask.tsk not
using binary command line.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Timers</title>
<para>
It currently uses a service thread, run in the context of the calling
process, which should correctly mimic Windows behavior.
</para>
<title>NT configuration</title>
<para>TODO:
<itemizedlist>
<listitem>
<para>
Check if minimal time is satisfactory for most programs.
</para>
</listitem>
<listitem>
<para>
current implementation may let a timer tick (once) after it has
been destroyed
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>MMIO</title>
<para>
The API consists of the mmio* functions found in dlls/winmm/mmio.c.
Seems to work ok in most of the cases. There's some linear/segmented
issues with 16 bit code. There are also some bugs when writing MMIO
files.
</para>
</sect2>
<sect2>
<title>sndPlayXXX functions</title>
<para>
Seem to work correctly.
Under the
<screen>
HKLM\Software\Microsoft\Windows NT\CurrentVersion
</screen>
key, are stored the names of the DLLs to be loaded for each
MCI driver name:
<screen>
"cdaudio"="mcicda.drv"
"sequencer"="mciseq.drv"
"waveaudio"="mciwave.drv"
"avivideo"="mciavi.drv"
"videodisc"="mcipionr.drv"
"vcr"="mcivisca.drv"
"MPEGVideo"="mciqtz.drv"
</screen>
</para>
</sect2>
</sect1>
<sect1 id="mm-conf">
<title>Multimedia configuration</title>
<para>
Currently, multimedia configuration heavily relies on Win 3.x
configuration model.
</para>
<sect2>
<title>Drivers</title>
<title><filename>system.ini</filename></title>
<para>
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 (built-in) or Windows (native) version.
Wine will read the MCI drivers from the
<literal>[mci]</literal> or <literal>[mci32]</literal>
section. Wine won't make any difference between the two.
</para>
</sect2>
<sect2>
<title>MCI</title>
<para>
A default [mci] section (in system.ini) looks like (see the note above
on videodisc):
</para>
Here's a sample configuration:
<screen>
[mci]
cdaudio=mcicda.drv
......@@ -953,333 +971,94 @@
vcr=mcivisca.drv
MPEGVideo=mciqtz.drv
</screen>
<para>
By default, the list of loadable MCI drivers will be made of those
drivers (in the [mci] section).
</para>
<para>
The list of loadable (recognized) MCI drivers can be altered in the
[option] section of the wine config file, like:
mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO
</para>
<para>TODO:
<itemizedlist>
<listitem>
<para>
use a default registry setting to bypass this (ugly) configuration
model
</para>
</listitem>
<listitem>
<para>
we need also a generic tool to let the end user pick
up his/her driver depending on the hardware present on the machine.
model
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Low level drivers</title>
<para>
Configuration of low level drivers is done with the Wine configuration file.
Default keys are provided in wine.inf.
ACM drivers' configuration is read (only so far) from the
<filename>system.ini</filename> (and setup at Wine
installation from the <filename>wine.inf</filename> file).
<screen>
[drivers32]
MSACM.imaadpcm=imaadp32.acm
MSACM.msadpcm=msadp32.acm
MSACM.msg711=msg711.acm
MSACM.winemp3=winemp3.acm
</screen>
</para>
<para>
The registry keys used here differ from the Windows' one. Using the Windows' one
would require implementing something equivalent to a (real) driver installation.
Even if this would be necessary in a few cases (mainly using MS native multimedia)
modules, there's no real need so far (or it hasn't been run into yet).
Video (aka vidc) drivers' configuration is read (only so
far) from the <filename>system.ini</filename> (and setup at
Wine installation from the <filename>wine.inf</filename>
file).
<screen>
[drivers32]
VIDC.MRLE=msrle32.dll
VIDC.MSVC=msvidc32.dll
VIDC.CVID=iccvid.dll
</screen>
</para>
<para>
See the configuration part of the User's Guide for more details.
See also the configuration part of the User's Guide for
other information on low level drivers.
</para>
</sect2>
<sect2>
<title>Per driver/DLL configuration</title>
<sect3>
<title>Midi mapper</title>
<para>
The Midi mapper configuration is the same as on Windows 9x. Under the key
The Midi mapper configuration is the same as on Windows
9x. Under the key:
<screen>
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap
</screen>
if the 'UseScheme' value is not set, or is set to a null value, the midi
mapper will always use the driver identified by the 'CurrentInstrument'
value. Note: Wine (for simplicity while installing) allows to define
'CurrentInstrument' as "#n" (where n is a number), whereas Windows only
allows the real device name here. If UseScheme is set to a non null value,
'CurrentScheme' defines the name of the scheme to map the different channels.
All the schemes are available with keys like
if the <literal>UseScheme</literal> value is not set, or
is set to a null value, the MIDI mapper will always use
the driver identified by the
<literal>CurrentInstrument</literal> value. Note: Wine
(for simplicity while installing) allows to define
<literal>CurrentInstrument</literal> as
<literal>#n</literal> (where n is a number), whereas
Windows only allows the real device name here. If
<literal>UseScheme</literal> is set to a non null value,
<literal>CurrentScheme</literal> defines the name of the
scheme to map the different channels. All the schemes are
available with keys like
<screen>
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\%name_of_scheme%
</screen>
For every scheme, under this key, will be a sub-key (which name is usually
a two digit index, starting at 00). Its default value is the name of the
output driver, and the value 'Channels' lists all channels (of the 16
standard MIDI ones) which have to be copied to this driver.
For every scheme, under this key, will be a sub-key (which
name is usually a two digit index, starting at 00). Its
default value is the name of the output driver, and the
value <literal>Channels</literal> lists all channels (of
the 16 standard MIDI ones) which have to be copied to this
driver.
</para>
<para>
To provide enhanced configuration and mapping capabilities, each driver
can define under the key
To provide enhanced configuration and mapping
capabilities, each driver can define under the key
<screen>
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Ports\%driver_name%
</screen>
a link to and .IDF file which allows to remap channels internally (for
example 9 -&gt; 16), to change instruments identification, event
controllers values. See the source file dlls/winmm/midimap/midimap.c
for the details (this isn't implemented yet).
</para>
</sect2>
<sect2>
<title>ACM</title>
<para>
To be done (use the same mechanism as MCI drivers configuration).
</para>
</sect2>
<sect2>
<title>VIDC</title>
<para>
To be done (use the same mechanism as MCI drivers configuration).
</para>
</sect2>
</sect1>
<sect1 id="mm-arch">
<title>Multimedia architecture</title>
<sect2>
<title>Windows 9x multimedia architecture</title>
<screen>
|
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 |
+--------+ | | +--------------+ +-----------+
| | | msacm.drv | | mciwave |
| | +--------------+ +-----------+
| | | midimap.drv | | mcimidi |
| | +-------------+ +-----------+
| | Low-level drivers | ... | MCI drivers
| | +----------+
| | |
| | |<16
| +-------------------------------+
|
</screen>
<para>
The important points to notice are:
<itemizedlist>
<listitem>
<para>
all drivers (and most of the core code) is 16 bit
</para>
</listitem>
<listitem>
<para>
all hardware (or most of it) dependent code reside in the kernel
space (which is not surprising)
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Wine multimedia architecture</title>
<screen>
|
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 | | | | MMSystem.dll
| | | mixerXXX | | | | 16 bit
| | | auxXXX +---+ +---+ mmThread| |
| | | joyXXX | Call back | mmTask | |
| | +-----------+-----------+---------+-------------+
| | || ^ ^ || ^^
| | 16>||<32 |<16>| 16>||<32>||<16
| | vv |<32>| vv ||
+---------+ | | +-------------+ +----------+
|HW driver|<------->| *.drv | | mci*.drv |
+---------+ | | +--------------+ +-----------+
| | | msacm.drv | | mciwave |
| | +--------------+ +-----------+
| | | midimap.drv | | mcimidi |
| | +-------------+ +-----------+
| | Low-level drivers | ... | MCI drivers
| | +----------+
| | |
| | |<32/16
| +-------------------------------+
|
</screen>
<para>
From the previous drawings, the most noticeable differences are:
<itemizedlist>
<listitem>
<para>
low-level drivers can either be 16 or 32 bit
</para>
</listitem>
<listitem>
<para>
MCI drivers can either be 16 or 32 bit
</para>
</listitem>
<listitem>
<para>
MMSystem and WinMM will be hosted in a single elfglue library
</para>
</listitem>
<listitem>
<para>
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
a link to and <filename>.IDF</filename> file which allows
to remap channels internally (for example 9 -&gt; 16), to
change instruments identification, event controllers
values. See the source file
<filename>dlls/winmm/midimap/midimap.c</filename> for the
details (this isn't implemented yet).
</para>
</listitem>
<listitem>
<para>
all built-in drivers (low-level and MCI) will be written as 32 bit
drivers
</para>
</listitem>
<listitem>
<para>
all native drivers will be 16 bits drivers
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<sect1 id="msacm">
<title>MS ACM Dlls</title>
<sect2>
<title>Contents</title>
<para>tbd</para>
</sect2>
<sect2>
<title>Status</title>
</sect3>
<para>tbd</para>
</sect2>
<sect2>
<title>Caching</title>
<para>
The MSACM/MSACM32 keeps some data cached for all known ACM
drivers. Under the key
<screen>
Software\Microsoft\AudioCompressionManager\DriverCache\&lt;driver
name&gt;
</screen>
, are kept for values:
<itemizedlist>
<listitem>
<para>
aFormatTagCache which contains an array of
DWORD. There are two DWORDs per cFormatTags
entry. The first DWORD contains a format tag
value, and the second the associated maximum
size for a WAVEFORMATEX structure.
(Fields dwFormatTag and cbFormatSize from
ACMFORMATDETAILS)
</para>
</listitem>
<listitem>
<para>
cFilterTags contains the number of tags supported by the driver
for filtering.
</para>
</listitem>
<listitem>
<para>
cFormatTags contains the number of tags support
by the driver for conversions.
</para>
</listitem>
<listitem>
<para>
fdwSupport (the same as the one returned from
acmDriverDetails).
</para>
</listitem>
</itemizedlist>
</para>
<para>
The cFilterTags, cFormatTags, fdwSupport are the same
values as the ones returned from acmDriverDetails
function.
</para>
</sect2>
</sect1>
</chapter>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment