From 3393730f9688b77c6ed0cd091653cc7e3b155d1e Mon Sep 17 00:00:00 2001 From: Eric Pouech Date: Wed, 8 Dec 1999 03:26:58 +0000 Subject: [PATCH] Updated, added chapter on configuration and architecture. --- documentation/status/multimedia | 806 +++++++++++++++++++++----------- 1 file changed, 523 insertions(+), 283 deletions(-) diff --git a/documentation/status/multimedia b/documentation/status/multimedia index 0174d3e695a..36fd01d11a9 100644 --- a/documentation/status/multimedia +++ b/documentation/status/multimedia @@ -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 -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 - file). + 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 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 (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. - + * 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 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 - file, and also some specfic defines because MIDI - is not supported on all OSes by OSS). + 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 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). - + 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 - + * 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 lowlevel driver functions in - multimedia/mixer.c using the mixMessage function. - -1.3.1 OSS implementation - - The current implementation uses the OpenSoundSystem 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 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 + * 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). - 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 - + 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 + * 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 - 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: - - better support of enhanced joysticks - - support more joystick drivers (like the XInput extension) + * 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) +--------------------------- -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. - 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...) + + 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 Builtin + 2.1.1 Built-in + 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.) - + 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); - -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...) - + * 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). -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 - + 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 + 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). - + + 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 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 + 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 Builtin - - The implementation consists of stubs and is in multimedia/mciavi.c. - - TODO: - - implement it, probably using xanim or something similair. - + 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 + +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). - + + 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: - - 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. + * 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, supercedes the mci - key in c:\windows\system.ini - + 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: - - 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. - + * 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 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 ---------- 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: - - 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 -------- + + 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: - - ... + + use a default registry setting to bypass this (ugly) configuration + model + +4.3 Low level drivers +--------------------- -@------------------------------------@ -@ Last updated: 12, May 1999 @ -@ Eric Pouech @ -@------------------------------------@ + 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/