                              Wine Documentation                               
Prev                    Chapter 13. Wine and Multimedia                    Next
-------------------------------------------------------------------------------

13.2. 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 (as built-in DLLs):

13.2.1. (Wave form) Audio

MMSYSTEM and WINMM call the real low level audio driver using the wodMessage/
widMessage which handles the different requests.

13.2.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 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.
   
13.2.1.2. Other sub systems

No other is available. Could think of Sun Audio, remote audio systems (using X
extensions, ...), ALSA, EsounD, ArTs...

13.2.2. MIDI

MMSYSTEM and WINMM call the low level driver functions using the midMessage and
the modMessage functions.

13.2.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 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)
   
13.2.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...

13.2.3. Mixer

MMSYSTEM and WINMM call the low level driver functions using the mixMessage
function.

13.2.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
   
13.2.3.2. Other sub systems

TODO:

  * implement mixing low level drivers for other mixers (ALSA...)
   
13.2.4. Aux

The AUX low level driver is the predecessor of the mixer driver (introduced in
Win 95).

13.2.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 ?
   
13.2.5. 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).

13.2.6. 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.
   
13.2.7. 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.

13.2.7.1. 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
   
13.2.7.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.

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

13.2.8.1. Built-in

A built-in MIDI mapper can be found in dlls/winmm/midimap/. It partly provides
the same functionnality 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)
   
13.2.8.2. 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.
   
-------------------------------------------------------------------------------
Prev                                 Home                                  Next
Wine and Multimedia                   Up                Mid level drivers (MCI)
