diff --git a/dlls/winmm/mciseq/mcimidi.c b/dlls/winmm/mciseq/mcimidi.c index dcc03874451..99c6406a56f 100644 --- a/dlls/winmm/mciseq/mcimidi.c +++ b/dlls/winmm/mciseq/mcimidi.c @@ -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 #include #include diff --git a/dlls/winmm/wineoss/midi.c b/dlls/winmm/wineoss/midi.c index 91ac4d8fd13..7a00d9b153c 100644 --- a/dlls/winmm/wineoss/midi.c +++ b/dlls/winmm/wineoss/midi.c @@ -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 diff --git a/dlls/winmm/wineoss/mixer.c b/dlls/winmm/wineoss/mixer.c index 1eb53af37d9..2174a2c93bd 100644 --- a/dlls/winmm/wineoss/mixer.c +++ b/dlls/winmm/wineoss/mixer.c @@ -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 @@ -990,7 +994,7 @@ static DWORD MIX_GetLineControls(WORD wDevID, LPMIXERLINECONTROLSA lpMlc, TRACE("[%d] => [%2d]: typ=%08lx\n", j, i + 1, mix->ctrl[i].ctrl.dwControlType); lpMlc->pamxctrl[j++] = mix->ctrl[i].ctrl; - } + } } } } diff --git a/dlls/winmm/winmm.c b/dlls/winmm/winmm.c index b413daa9691..a86ae5cc7e3 100644 --- a/dlls/winmm/winmm.c +++ b/dlls/winmm/winmm.c @@ -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 #include #include diff --git a/documentation/multimedia.sgml b/documentation/multimedia.sgml index c02f9fab313..fdb4af7c251 100644 --- a/documentation/multimedia.sgml +++ b/documentation/multimedia.sgml @@ -7,10 +7,12 @@ - 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 + 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). @@ -23,1051 +25,32 @@ and MSVIDEO/MSVFW32 pairs). - - 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. - - - - There are two specific low level drivers (msacm.drv for wave input/output, - midimap.drv for MIDI output only), whose role is: - - - - help choosing one low level driver between many - - - - - add the possibility to convert streams (ie ADPCM => - PCM) (this is useful if the format required by the - application for playback isn't supported by the soundcard). - - - - - add the possibility to filter a stream (adding echo, equalizer... - to a wave stream), or modify the instruments that have to be - played (MIDI). - - - - - All of those components are defined as DLLs (one by one). - - - - 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 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...). + + + Mid level (MCI) and high level layers must be written independently from + the hardware and OS services. - The following low level layers are implemented (as built-in DLLs): + MCI level provides some coarser grain operations (like playing + a Midi file, or playing a video stream). - - (Wave form) Audio - - - MMSYSTEM and WINMM call the real low level audio driver using the - wodMessage/widMessage which handles the different requests. - - - - OSS implementation - - - The low level audio driver is currently only implemented for the - OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by - 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). - - - - 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. - - - TODO: - - - - verify all functions for correctness - - - - - Add virtual mixer between wave-out and dsound interfaces. - - - - - - - - - Other sub systems - - - Support is also provided for ALSA, aRts, NAS, Jack, - AudioIO, but with less intensive debugging than the OSS. - - - - EsounD isn't supported yet. ALSA support still needs a - couple of refinements. - - - - - - - - MIDI - - - MMSYSTEM and WINMM call the low level driver functions using the - midMessage and the modMessage functions. - - - - OSS driver - - - The low level audio driver is currently only implemented for the - OpenSoundSystem (OSS) as supplied in the Linux and FreeBSD kernels by - 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 a 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) - - - - - - - - - Other sub systems - - - Could support other MIDI implementation for other sub - systems (ALSA, any other 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... - Note: this could be achieved using the ALSA sequencer and - Timidity being used as a server. - - - - - - - - Mixer - - - MMSYSTEM and WINMM call the low level driver functions using the - mxdMessage function. - - - - 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 - - - - - - - - - Other sub systems - - TODO: - - - - implement mixing low level drivers for other mixers (ALSA...) - - - - - - - - - - - Aux - - - The AUX low level driver is the predecessor of the mixer driver - (introduced in Win 95). - - - - 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 ? - - - - - - - - - - - - Wine OSS - - - 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). - - - - - - Joystick - - - 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. - - - TODO: - - - - better support of enhanced joysticks (Linux 2.2 interface is available) - - - - - support more joystick drivers (like the XInput extension) - - - - - should load joystick DLL as any other driver (instead of hardcoding) - the driver's name, and load it as any low lever driver. - - - - - - - - - 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. - - - - Built-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 built-in ACM driver in Wine, so you must use - native ones if you're looking for non PCM playback. - - - TODO: - - - - check for correctness and robustness - - - - - - - - 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. - - - - - - - - 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. - - - - Built-in - - - 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). - - - TODO: - - - - 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) - - - - - - - - - Native - - - 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. - - - TODO: - - - - add native midimapper keys to the registry to let it run. This - will require proper multimedia driver installation routines. - - - - - - - - - - - - - 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 - - - - - - - - CDAUDIO - - - 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 - 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.) - - - - 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 (plus a decent - configuration scheme) - - - - - - - - - Native - - - Native MCICDA works also correctly... It uses the MSCDEX traps (on int - 2f). However, some commands (like seeking) seem to be broken. - - - - - - - - MCIWAVE - - - 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 - - - - - better implement non waiting command (without the MCI_WAIT flag). - - - - - - - - - Native - - - Native MCIWAVE works also correctly. - - - - - - - - MCISEQ (MIDI sequencer) - - - Built-in - - - 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). - - - 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 - - - - - - - - - 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 - - - - - - - - - - - MCIANIM - - - Built-in - - - The implementation is in dlls/winmm/mcianim/. - - - TODO: - - - - implement it, probably using xanim or something similar. - - - - - - - - - Native - - - Native MCIANIM is reported to work (but requires native video DLLs - also, even though the built-in video DLLs start to work correctly). - - - - - - - - MCIAVI - - - Built-in - - - 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. - - - TODO: - - - - finish the implementation - - - - - fix the audio/video synchronization issue - - - - - - - - - Native - - - Native MCIAVI is reported to work (but requires native video DLLs - also). Some files exhibit some deadlock issues anyway. - - - - - - - - - - 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). - 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. - - - 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 - - - - - - - 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 builtin, native), 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 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. - - - 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) - - - - - implement auto-open feature (ie, when a string command is issued - for a not yet opened device, MCI automatically opens it) - - - - - - - - - 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. - - - - - - - - - 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 - - - - - - - - - MMIO - - - 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. - - - - - - sndPlayXXX functions - - - Seem to work correctly. - - - - - - - - Multimedia configuration - - - Currently, multimedia configuration heavily relies on Win 3.x - configuration model. - - - - 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 (built-in) or Windows (native) version. - - - - - - 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 the wine config file, like: - mci=CDAUDIO:SEQUENCER:WAVEAUDIO:AVIVIDEO:MPEGVIDEO - - - TODO: - - - - use a default registry setting to bypass this (ugly) configuration - model - - - - - 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 - - - - - - - - - Low level drivers - - - Configuration of low level drivers is done with the Wine configuration file. - Default keys are provided in wine.inf. - - - - 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). - - - - See the configuration part of the User's Guide for more details. - - - - - - Midi mapper - - - The Midi mapper configuration is the same as on Windows 9x. Under the key - -HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap - - 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 - -HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\%name_of_scheme% - - 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. - - - - To provide enhanced configuration and mapping capabilities, each driver - can define under the key - -HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Ports\%driver_name% - - a link to and .IDF file which allows to remap channels internally (for - example 9 -> 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). - - - - - ACM - - - To be done (use the same mechanism as MCI drivers configuration). - - - - - - VIDC - - - To be done (use the same mechanism as MCI drivers configuration). - - - - Multimedia architecture - Windows 9x multimedia architecture + Windows 95 multimedia architecture | @@ -1094,9 +77,9 @@ Kernel space | Client applications +--------+ | | | auxXXX +---+ +---+ mmThread| | |MMDEVLDR|<------->| joyXXX | Call back | mmTask | | +--------+ | | +-----------+-----------+---------+-------------+ - ^ | | | ^ ^ | ^ - | | | 16>| |<16>| 16>| |<16 - v | | v | | v | + ^ | | | ^ ^ | ^ + | | | 16>| |<16>| 16>| |<16 + v | | v | | v | +--------+ | | +-------------+ +----------+ | VxD |<------->| *.drv | | mci*.drv | +--------+ | | +--------------+ +-----------+ @@ -1131,6 +114,40 @@ Kernel space | Client applications + + Windows NT multimedia architecture + + + 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. + + + + The important points to notice (compared to the Windows 95 + architecture) are: + + + + drivers (low level, MCIs...) are 32 bit and Unicode + + + + + 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). + + + + + + Wine multimedia architecture @@ -1154,9 +171,9 @@ Kernel space | Client applications | | | auxXXX +---+ +---+ mmThread| | | | | joyXXX | Call back | mmTask | | | | +-----------+-----------+---------+-------------+ - | | || ^ ^ || ^^ - | | 16>||<32 |<16>| 16>||<32>||<16 - | | vv |<32>| vv || + | | || ^ ^ | ^ + | | 16>||<32 |<16>| 16>| |<16 + | | vv |<32>| 32>v |<32 +---------+ | | +-------------+ +----------+ |HW driver|<------->| *.drv | | mci*.drv | +---------+ | | +--------------+ +-----------+ @@ -1177,7 +194,8 @@ Kernel space | Client applications - low-level drivers can either be 16 or 32 bit + low-level drivers can either be 16 or 32 bit (in fact, + Wine supports only native wave and audio mappers). @@ -1185,32 +203,431 @@ Kernel space | Client applications 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 + + + + + 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. + + + + + + + + Low level layers + + + 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. + + + + 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. + + + + 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: + + + + choosing one low level driver between many (we'll + discuss how the choice is made later on) + + + + + add the possibility to convert stream's format (ie ADPCM => + PCM) (this is useful if the format required by the + application for playback isn't supported by the soundcard). + + + + + 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). + + + + + + + Hardware-bound low level drivers + + + Each low lever driver has to implement at least one of the + following functionality, through the named function: + - all native drivers will be 16 bits drivers + Waveform audio: out for playback, and in for + recording. MMSYSTEM and WINMM call the real low level + audio driver using the driver's + wodMessage and + widMessage functions which handle + the different requests. + + + + + 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 + midMessage and the + modMessage functions. + + + + + 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 + mxdMessage function. + + + + + Aux: this is the predecessor of the mixer + functionnality (introduced in Win 95). Its usage has + been deprecated in favor of mixer interfaces. + + Wine currently supports the following (kernel) multimedia + interfaces. + + + + Open Sound System (OSS) as supplied in the Linux and + FreeBSD kernels by 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. + + + + + Advanced Linux Sound Architecture (ALSA) as + supplied in the Linux kernel. Source code resides in + dlls/winmm/winealsa. + + + + + Analog RealTime Synthetizer (aRts): a + network server (and virtual mixer) used in the KDE project. + + + + + Network Audio Server (NAS): an + audio server. + + + + + Jack: a + low latency audio server. + + + + + AudioIO: the native Solaris audio interface. + + + + + + + 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): + + Wine multimedia drivers' functionalities + + + + Driver + Wave Out + Wave In + Midi Out + Midi In + Mixer (and Aux) + + + + + OSS + Yes + Yes + Yes + Yes + Yes + + + ALSA + Yes + Yes + Yes + Yes + Yes + + + aRts + Yes + Yes + No + No + Yes + + + NAS + Yes + Yes + No + No + Yes + + + AudioIO + Yes + Yes + No + No + Yes + + + Jack + Yes + Yes + No + No + Yes + + + +
+ + + + 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. + + + + + + Wave mapper (msacm.drv) + + + 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. + + + + 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). A Law, uLaw, + ADPCM, MP3... fit into the category of non PCM formats. + + + + + + MIDI mapper (midimap.drv) + + + 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. + + + + 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). + + + + + + + + Mid level drivers (MCI) + + + The mid level drivers are represented by some common API + functions, mostly mciSendCommand and + mciSendString. Wine implements several + MCI mid level drivers. + + + + + Wine MCI drivers + + + + MCI Name + DLL Name + Role + Location + Comments + + + + + CdAudio + MciCDA.drv + MCI interface to a CD audio player + dlls/winmm/mcicda/ + + Relies on NTDLL CdRom raw interface (through + DeviceIoControl). + + + + WaveAudio + MciWave.drv + + MCI interface for wave playback and record + + dlls/winmm/mciwave/ + It uses the low level audio API. + + + Sequencer + MciSeq.drv + Midi Sequencer (playback) + dlls/winmm/mciseq/ + It uses the low level midi APIs + + + AviVideo + MciAvi.drv + AVI playback and record + dlls/winmm/mciavi/ + + It rather heavily relies on MSVIDEO/MSVFW32 DLLs + pair to work. + + + + +
+ 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). + + + + 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 wine.inf + + + + + + High level layers + + + WINMM (and MMSYSTEM) + + + 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). + + + + 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. + + + + 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. + + + + 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. + + + + + + DSOUND + + + Wine also provide a DSound (DirectX) DLL with the proper + COM implementation. + + + + Note that a Wine specific flag has been added to the + wodOpen 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. + + @@ -1221,13 +638,61 @@ Kernel space | Client applications Contents - tbd - + + 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. + + + + 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): + + Wine ACM drivers + + + + Name + Provides + + + + + imaadp32 + IMA ADPCM (adaptative PCM) + + + msadp32 + Microsoft's ADPCM (adaptative PCM) + + + msg711 + Microsoft's G.711 (A-Law and µ-Law) + + + winemp3 + + Wine's MP3 (MPEG Layer 3), based on mpglib library + + + + +
+ - - Status + + Note that Wine also supports native audio codecs as + well. + + + + All builtin ACM drivers are 32 bit Unicode DLLs + - tbd @@ -1237,51 +702,365 @@ Kernel space | Client applications The MSACM/MSACM32 keeps some data cached for all known ACM drivers. Under the key - Software\Microsoft\AudioCompressionManager\DriverCache\<driver - name> + Software\Microsoft\AudioCompressionManager\DriverCache\<driver name> , are kept for values: - - - - 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) - - - - - cFilterTags contains the number of tags supported by the driver - for filtering. - - - - - cFormatTags contains the number of tags support - by the driver for conversions. - - - - - fdwSupport (the same as the one returned from - acmDriverDetails). - - - - + + + + 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) + + + + + cFilterTags contains the number of tags supported by the driver + for filtering. + + + + + cFormatTags contains the number of tags support + by the driver for conversions. + + + + + fdwSupport (the same as the one returned from + acmDriverDetails). + + + + - The cFilterTags, cFormatTags, fdwSupport are the same - values as the ones returned from acmDriverDetails - function. + The cFilterTags, + cFormatTags, + fdwSupport are the same values as the + ones returned from acmDriverDetails + function. + + MS Video Dlls + + + Contents + + + 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. + + + + There's nothing specific in Wine's implementation compared + to Windows' one. Here's however a list of the builtin + decoding drivers: + + Wine VIDC drivers + + + + Name + Provides + + + + + msrle32 + Microsoft's RLE (Run-Length encoded) + + + msvidc32 + Microsoft's Video-1 + + + iccvid + Radius Cinepak Video Decoder + + + +
+ + + + Note that Wine also supports native video codecs as well. + + + + All builtin VIDC drivers are 32 bit Unicode DLLs + + + + + + + + Multimedia configuration + + + Unfortunately, multimedia configuration evolved over time: + + + + In the early days on Windows 3.x, configuration was + stored in system.in file, under + various sections ([drivers] for low + level drivers, [mci] + (resp. [mci32]) for 16 bit (resp. 32 + bit) MCI drivers...). + + + + + With the apparition of the registry, in Windows 95, + configuration as been duplicated there, under the key + +HKLM\System\CurrentControlSet\Control\MediaResources + + + + + + Windows NT also adopted the registry, but decided to + store the configuration information under another key + than Windows 9x did. + +HKLM\Software\Microsoft\Windows NT\CurrentVersion + + And with a different layout of keys and values beneath + this key. + + + + + + + Currently, Wine tries to load first a driver (low-level or + MCI) from the NT registry settings. If it fails, it will try + the system.ini configuration. + + + + An out-of-the-box configuration is provided in + wine.inf, and shall be stored in registry + and system.ini 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 + winecfg. + + + + Wine multimedia configuration scheme + + + + Driver + Read from NT registry + Read from system.ini + Setup by wine.inf + Setup by winecfg + + + + + MCI drivers + Yes (1) + Yes (2) + Yes + No + + + Wave and MIDI mappers + Yes + No + Yes + No + + + Hardware-bound low level drivers + Yes + No + No + Yes + + + ACM and VIDC drivers (audio & video codecs) + No + Yes + Yes + No + + + +
+ + + 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. + + + + 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). + + + + The following sections describe which type of information + (depending on the location) Wine's multimedia DLLs understand. + + + + NT configuration + + + Under the + +HKLM\Software\Microsoft\Windows NT\CurrentVersion + + key, are stored the names of the DLLs to be loaded for each + MCI driver name: + + "cdaudio"="mcicda.drv" + "sequencer"="mciseq.drv" + "waveaudio"="mciwave.drv" + "avivideo"="mciavi.drv" + "videodisc"="mcipionr.drv" + "vcr"="mcivisca.drv" + "MPEGVideo"="mciqtz.drv" + + + + + + <filename>system.ini</filename> + + + Wine will read the MCI drivers from the + [mci] or [mci32] + section. Wine won't make any difference between the two. + + + + Here's a sample configuration: + + [mci] + cdaudio=mcicda.drv + sequencer=mciseq.drv + waveaudio=mciwave.drv + avivideo=mciavi.drv + videodisc=mcipionr.drv + vcr=mcivisca.drv + MPEGVideo=mciqtz.drv + + + + + ACM drivers' configuration is read (only so far) from the + system.ini (and setup at Wine + installation from the wine.inf file). + + [drivers32] + MSACM.imaadpcm=imaadp32.acm + MSACM.msadpcm=msadp32.acm + MSACM.msg711=msg711.acm + MSACM.winemp3=winemp3.acm + + + + + Video (aka vidc) drivers' configuration is read (only so + far) from the system.ini (and setup at + Wine installation from the wine.inf + file). + + [drivers32] + VIDC.MRLE=msrle32.dll + VIDC.MSVC=msvidc32.dll + VIDC.CVID=iccvid.dll + + + + + See also the configuration part of the User's Guide for + other information on low level drivers. + + + + + + Per driver/DLL configuration + + + Midi mapper + + + The Midi mapper configuration is the same as on Windows + 9x. Under the key: + +HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap + + 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 + +HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\%name_of_scheme% + + 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. + + + + To provide enhanced configuration and mapping + capabilities, each driver can define under the key + +HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Ports\%driver_name% + + a link to and .IDF file which allows + to remap channels internally (for example 9 -> 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). + + + + + + + +