| 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) lowlevel drivers. The |
| implementation can be found in the multimedia/ subdirectory. |
| |
| The multimedia stuff is split into 3 layers. The lowlevel (device |
| drivers), midlevel (MCI commands) and highlevel abstraction layers. |
| |
| The lowlevel may depend on current hardware and OS services (like |
| OSS). Mid-level and high-level must be written independantly from the |
| hardware and OS services. |
| |
| 1. Lowlevel layers |
| ================== |
| |
| Please note that native low-level drivers are not currently |
| supported in WINE, because they either access hardware composants |
| or require VxDs to be loaded; WINE does not correctly supports |
| those two so far. |
| |
| Following lowlevel layers are implemented: |
| |
| 1.1 (Waveform) Audio |
| -------------------- |
| |
| MMSYSTEM and WINMM call the real lowlevel audiodriver using |
| the wodMessage/widMessage function in multimedia/audio.c, which |
| handles the different requests. |
| |
| 1.1.1 OSS implementation |
| |
| The lowlevel audio driver is currently only implemented for the |
| OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels |
| by 4Front Technologies (http://www.4front-tech.com/). The presence |
| of this driver is checked by configure (depends on the |
| <sys/soundcard.h> file). |
| |
| The implementation contains all features commonly used, but has |
| several problems (see TODO list). |
| |
| TODO: |
| - add asynchronous reads (must use threads) as done for writes |
| - verify all functions for correctness |
| - add drivers for other soundsystems (Sun Audio, remote audio |
| systems (using X extensions, ...), ALSA |
| - WaveHdr must be sent though mmsystem.c to get the linear |
| address set correctly. An application calling directly |
| (wod|wid)Message will fail |
| |
| 1.1.2 Wave mapper |
| |
| The Wave mapper device allows to load on-demand codecs to perform |
| software conversion for the types the actual low level driver |
| (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 |
| -------- |
| |
| MMSYSTEM and WINMM call the lowlevel driver functions in |
| multimedia/midi.c using the midMessage and the modMessage |
| functions. |
| |
| 1.2.1 OSS driver |
| |
| The lowlevel audio driver is currently only implemented for the |
| OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels |
| by 4Front Technologies (http://www.4front-tech.com/). The presence |
| of this driver is checked by configure (depends on the |
| <sys/soundcard.h> file, and also some specfic defines because MIDI |
| is not supported on all OSes by OSS). |
| 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: |
| - Do not implement a software synthesizer. This should be done |
| using MIDI loopback devices in an external program (like |
| timidity). The only trouble is that timidity is GPL'ed... |
| - 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 ? |
| - MidiHdr must be sent though mmsystem.c to get the linear |
| address set correctly. An application calling directly |
| (wod|wid)Message will fail |
| - implement asynchronous playback of MidiHdr (regular and/or |
| stream) |
| - use a more accurate read mechanism than the one of snooping |
| on timers |
| |
| 1.2.2 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. |
| |
| TODO: |
| - implement the Midi mapper |
| |
| 1.3 Mixer |
| --------- |
| |
| MMSYSTEM and WINMM call the lowlevel driver functions in |
| multimedia/mixer.c using the mixMessage function. |
| |
| 1.3.1 OSS implementation |
| |
| The current implementation uses the OpenSoundSystem mixer. |
| |
| TODO: |
| - implement mixing mute functionality for OSS. |
| - implement mixing lowlevel drivers for other mixers (ALSA...) |
| - implement notification mechanism when state of mixer's |
| controls change |
| - handlers used for mixer are currently poorly implemented |
| |
| 1.4 AUX |
| ------- |
| |
| The API consists of the aux* functions found in |
| 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. |
| |
| 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.7 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. |
| |
| TODO: |
| - better support of enhanced joysticks |
| - support more joystick drivers (like the XInput extension) |
| |
| 2. Midlevel drivers (MCI) |
| ========================= |
| |
| The midlevel drivers are represented by some common API functions, |
| mostly mciSendCommand and mciSendString. |
| See status in chapter 3 for more information. |
| |
| WINE implements several MCI midlevel drivers (status is given for |
| both builtin and native implementation): |
| |
| TODO: (apply to all builtin MCI drivers) |
| - move mci drivers as regular DLLs (loading in wine, |
| elfglue...) |
| |
| 2.1 CDAUDIO |
| ----------- |
| |
| 2.1.1 Builtin |
| |
| The currently best implementation is the MCI CDAUDIO driver that can |
| be found in multimedia/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 similair, but are not implemented.) |
| |
| A very small example of a cdplayer consists just of the line |
| mciSendString("play cdaudio",NULL,0,0); |
| |
| 2.1.2 Native |
| |
| Native MCICDA works also correctly... It uses the mscdex traps (on |
| int 2f). |
| |
| TODO: |
| - add support for other cdaudio drivers (Solaris...) |
| |
| 2.2 MCIWAVE |
| ----------- |
| |
| 2.2.1 Builtin |
| |
| The implementation is rather complete and can be found in |
| multimedia/audio.c. |
| It uses the lowlevel 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 Builtin |
| |
| The implementation can be found in multimedia/midi.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). |
| |
| 2.4 MCIANIM |
| ----------- |
| |
| 2.4.1 Builtin |
| |
| The implementation consists of stubs and is in |
| multimedia/mcianim.c. |
| |
| TODO: |
| - implement it, probably using xanim or something similair. |
| |
| 2.4.2 Native |
| |
| Native MCIANIM is reported to work (but requires native video DLLs |
| also). |
| |
| 2.5 MCIAVI |
| ---------- |
| |
| 2.5.1 Builtin |
| |
| The implementation consists of stubs and is in multimedia/mciavi.c. |
| |
| TODO: |
| - implement it, probably using xanim or something similair. |
| |
| 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 skeletton for the core functionnalites for |
| multimedia rendering. |
| |
| Note that native mmsystem and WINMM do not currently under WINE |
| and there is no plan to support them (it would require to also |
| fully support VxD, which is not done yet). |
| |
| TODO: |
| - allow a dynamic loading of low level driver (should have one |
| for OSS, another one for ALSA...) |
| - add clean-up mechanisms when process detach from MM DLLs |
| - reimplement the sndPlay??? functions using MCI commands |
| rather than rewriting everything from scratch. |
| - prepare for the 16/32 bit split |
| - check thread-safeness for MMSYSTEM and WINMM entry points |
| |
| 3.1 MCI skeletton |
| ----------------- |
| |
| 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. |
| |
| 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, supercedes the mci |
| key in c:\windows\system.ini |
| |
| TODO: |
| - MCI command loading support mci(Load|Free)Command |
| - implement other stuff as yet unknown |
| - in mciString(), make use of hiword from mciSendMessage |
| return value to convert value into string... |
| - mmTaskXXX functions are currently broken because the 16 |
| loader does not support binary command lines. |
| |
| 3.2 MCI multi-tasking |
| --------------------- |
| Multi-tasking capabilities used for the MCI drivers are provided |
| in multimedia/mmsystem.c |
| |
| 3.3 Timers |
| ---------- |
| |
| It currently uses a service thread, run in the context of the calling |
| process, which should correctly mimic Windows behaviour. |
| |
| TODO: |
| - Check if minimal time is satisfactory for most programs. |
| |
| 3.4 MMIO |
| -------- |
| |
| The API consists of the mmio* functions found in multimedia/mmio.c. |
| |
| Seems to work ok in most of the cases. |
| |
| TODO: |
| - ... |
| |
| @------------------------------------@ |
| @ Last updated: 12, May 1999 @ |
| @ Eric Pouech <eric.pouech@lemel.fr> @ |
| @------------------------------------@ |