documentation/status/multimedia

   This file contains information about the implementation of the
   multimedia layer of WINE. The libraries consist of MMSYSTEM.DLL
   (win16), WINMM.DLL (win32) and some (abstracted, not Windows
   compatible) low level drivers.
   
   The implementation can be found in the dlls/winmm/ sub directory.
   
0. Overview
===========
                                       
   The multimedia stuff is split into 3 layers. The low level (device
   drivers), mid level (MCI commands) and high level abstraction layers.
   
   The low level may depend on current hardware and OS services (like
   OSS). Mid level (MCI) and high level must be written independently
   from the hardware and OS services.
   There are two specific low level drivers call mappers (for wave and
   +midi) whose role is to :
     * help choosing one low level driver between many
     * add the possibility to convert stream (ie ADPCM => PCM)
     * add the possibility to filter a stream (adding echo, equalizer...)
       
   All of those components are defined as DLLs (one by one) and are
   candidate for dllglue migration.
   
1. Low level layers
===================
                                       
   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.
   
   The following low level layers are implemented:
   
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
   several problems (see TODO list).
   
   TODO:
     * add asynchronous reads [recording] (must use threads) as done for
       writes [playing]
     * verify all functions for correctness
     * looping of WaveHdr will fail
     * share access to /dev/dsp with dsound interface (either on a
       descriptor basis, or using a virtual mixer between different wave
       inputs. EsounD provides this type of capability).
       
  1.1.2 Other sub systems
  
   None are available. Could think of Sun Audio, remote audio systems
   (using X extensions, ...), ALSA, EsounD
   
1.2 MIDI
--------

   MMSYSTEM and WINMM call the low level driver functions using the
   midMessage and the modMessage functions.
   
  1.2.1 OSS driver
  
   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, and also some
   specific defines because MIDI is not supported on all OSes by OSS).
   Source code resides in dlls/winmm/wineoss/midi.c
   
   Both Midi in and Midi out are provided. The type of MIDI devices
   supported is external MIDI port (requires an MIDI capable device -
   keyboard...) and OPL/2 synthesis (the OPL/2 patches for all
   instruments are in midiPatch.c).
   
   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)
       
  1.2.2 Other sub systems
  
   Could support other midi implementation for other sub systems (any
   idea here ?)
   
   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...
   
1.3 Mixer
---------

   MMSYSTEM and WINMM call the low level driver functions using the
   mixMessage function.
   
  1.3.1 OSS implementation
  
   The current implementation uses the OpenSoundSystem mixer, and resides
   in dlls/winmm/wineoss/mixer.c
   
   TODO:
     * implement notification mechanism when state of mixer's controls
       change
       
1.3.2 Other sub systems

   TODO:
     * implement mixing low level drivers for other mixers (ALSA...)
       
1.4 AUX
-------

   The AUX low level driver is the predecessor of the mixer driver
   (introduced in Win 95).
   
  1.4.1 OSS driver
  
   The implementation uses the OSS mixer API, and is incomplete.
   
   TODO:
     * verify the implementation
     * check with what is done in mixer
     * open question: shall we implement it on top of the low level mixer
       functions ?
       
1.5 Joystick
------------

   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:
     * better support of enhanced joysticks
     * 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)
---------------------------

   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.
   
   
  1.6.1 Build-in
  
   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 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.
   
   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.1 Built-in
  
   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
   misc/cdrom.c Wine internal cdrom interface.
   This interface has been ported on Linux, FreeBSD and NetBSD. (Sun
   should be similar, but are not implemented.)
   
   A very small example of a cdplayer consists just of the line
   mciSendString("play cdaudio",NULL,0,0);
   
   TODO:
     * 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.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).
   
   FIXME:
     * The MCI_STATUS command is broken.
       
   TODO:
     * 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.
   
2.3 MCISEQ (MIDI sequencer)
---------------------------

  2.3.1 Built-in
  
   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).
   
   TODO:
     * implement it correctly
     * finish asynchronous commands (especially for reading/record)
     * better implement non waiting command (without the MCI_WAIT flag).
       
  2.3.2 Native
  
   Native MCIMIDI has been working but is currently blocked by 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.1 Built-in
  
   The implementation consists of stubs and is in dlls/winmm/mcianim.c.
   
   TODO:
     * implement it, probably using xanim or something similar.
       
  2.4.2 Native
  
   Native MCIANIM is reported to work (but requires native video DLLs
   also).
   
2.5 MCIAVI
----------

  2.5.1 Built-in
  
   The implementation consists of stubs and is in
   dlls/winmm/mciavi/mciavi.c.
   
   TODO:
     * implement it, probably using xanim or something similar.
       
2.5.2 Native

   Native MCIAVI is reported to work (but requires native video DLLs
   also). Some files exhibit some deadlock issues anyway.
   
3 High level layers
===================
                                       
   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).
   MCI and low level drivers can either be 16 or 32 bit.
   
   TODO:
     * it seems that some program check what's installed in registry
       against value returned by drivers. Wine is currently broken
       regarding this point.
     * add clean-up mechanisms when process detaches from MM DLLs
     * prepare for the 16/32 big split
     * check thread-safeness for MMSYSTEM and WINMM entry points
     * unicode entry points are badly supported
       
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
   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:
    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
       
   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:
     * correctly handle the MCI_ALL_DEVICE_ID in functions.
     * finish mapping 16 <=> 32 of MCI structures and commands
     * MCI_SOUND is not handled correctly (should not be sent to MCI
       driver => same behavior as MCI_BREAK)
     * do not display module warning when failed to 32-bit load a 16 bit
       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
---------------------

   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
----------

   It currently uses a service thread, run in the context of the calling
   process, which should correctly mimic Windows behavior.
   
   TODO:
     * 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
--------

   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.
   
3.5 sndPlayXXX functions
------------------------

   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:
   
     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.
   
   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/