docs: wine-devel [11/16]
Eric Pouech
pouech-eric at wanadoo.fr
Sun Sep 21 13:44:28 CDT 2003
Dimitrie O. Paun wrote:
> Eric, a lot of stuff in here looks like it's in
> need of some TLC, if you can take a look...
TLC ? tender & loving care ????
is that what you're looking for ? (even if everything is not filled in yet)
A+
--
Eric Pouech
-------------- next part --------------
Index: documentation/multimedia.sgml
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/documentation/multimedia.sgml,v
retrieving revision 1.9
diff -u -r1.9 multimedia.sgml
--- documentation/multimedia.sgml 21 Jul 2003 22:42:50 -0000 1.9
+++ documentation/multimedia.sgml 12 Aug 2003 18:55:10 -0000
@@ -15,7 +15,7 @@
<para>
Written by &name-eric-pouech; <email>&email-eric-pouech;</email>
- (Last updated: 02/16/2001)
+ (Last updated: 02/02/2003)
</para>
<sect1 id="mm-overview">
@@ -35,8 +35,8 @@
</para>
<para>
- There are two specific low level drivers (one for wave input/output,
- another one for MIDI output only), whose role is:
+ There are two specific low level drivers (msacm.drv for wave input/output,
+ midimap.drv for MIDI output only), whose role is:
<itemizedlist>
<listitem>
<para>
@@ -45,7 +45,9 @@
</listitem>
<listitem>
<para>
- add the possibility to convert streams (ie ADPCM => PCM)
+ 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).
</para>
</listitem>
<listitem>
@@ -130,8 +132,13 @@
<title>Other sub systems</title>
<para>
- No other is available. Could think of Sun Audio, remote audio systems
- (using X extensions, ...), ALSA, EsounD, ArTs...
+ Support is also provided for ALSA, aRts, NAS, Jack,
+ AudioIO, but with less intensive debugging than the OSS.
+ </para>
+
+ <para>
+ EsounD isn't supported yet. ALSA support still needs a
+ couple of refinements.
</para>
</sect3>
@@ -207,14 +214,16 @@
<title>Other sub systems</title>
<para>
- Could support other MIDI implementation for other sub systems (any
- idea here ?)
+ Could support other MIDI implementation for other sub
+ systems (ALSA, any other idea here ?)
</para>
<para>
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.
</para>
</sect3>
@@ -503,7 +512,7 @@
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.
+ 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.)
</para>
@@ -526,12 +535,6 @@
configuration scheme)
</para>
</listitem>
- <listitem>
- <para>
- The DLL is not cleanly separated from the NTDLL DLL. The CDROM
- interface should be exported someway (or stored in a Wine only DLL)
- </para>
- </listitem>
</itemizedlist>
</para>
@@ -767,16 +770,6 @@
</listitem>
<listitem>
<para>
- add clean-up mechanisms when process detaches from MM DLLs
- </para>
- </listitem>
- <listitem>
- <para>
- prepare for the 16/32 big split
- </para>
- </listitem>
- <listitem>
- <para>
check thread-safeness for MMSYSTEM and WINMM entry points
</para>
</listitem>
@@ -804,9 +797,9 @@
<para>
MCI drivers are seen as regular Wine modules, and can be loaded (with
- a correct load order between builtin, native, so), as any
- other DLL. Please note, that MCI drivers module names must bear the
- .drv extension to be correctly understood.
+ 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.
</para>
<para>
@@ -872,13 +865,6 @@
using binary command line.
</para>
</listitem>
- <listitem>
- <para>
- the Wine native MCI drivers should use the mmThreadXXX API (but since
- all built-in MCI drivers are 32 bit, this would require a special
- flag to mark 32 bit entry points)
- </para>
- </listitem>
</itemizedlist>
</para>
@@ -992,6 +978,13 @@
model
</para>
</listitem>
+ <listitem>
+ <para>
+ 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
+ </para>
+ </listitem>
</itemizedlist>
</para>
@@ -1227,35 +1220,35 @@
</sect1>
- <sect1 id="msacm">
- <title>MS ACM Dlls</title>
+ <sect1 id="msacm">
+ <title>MS ACM Dlls</title>
- <sect2>
- <title>Contents</title>
+ <sect2>
+ <title>Contents</title>
- <para>tbd</para>
- </sect2>
+ <para>tbd</para>
+ </sect2>
- <sect2>
- <title>Status</title>
+ <sect2>
+ <title>Status</title>
- <para>tbd</para>
- </sect2>
+ <para>tbd</para>
+ </sect2>
- <sect2>
- <title>Caching</title>
+ <sect2>
+ <title>Caching</title>
- <para>
- The MSACM/MSACM32 keeps some data cached for all known ACM
- drivers. Under the key
- <screen>
+ <para>
+ The MSACM/MSACM32 keeps some data cached for all known ACM
+ drivers. Under the key
+ <screen>
Software\Microsoft\AudioCompressionManager\DriverCache\<driver
name>
- </screen>
- are kept for values:
- <itemizedlist>
- <listitem>
- <para>
+ </screen>
+ , are kept for values:
+ <itemizedlist>
+ <listitem>
+ <para>
aFormatTagCache which contains an array of
DWORD. There are two DWORDs per cFormatTags
entry. The first DWORD contains a format tag
@@ -1263,37 +1256,36 @@
size for a WAVEFORMATEX structure.
(Fields dwFormatTag and cbFormatSize from
ACMFORMATDETAILS)
- </para>
- </listitem>
- <listitem>
- <para>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
cFilterTags contains the number of tags supported by the driver
for filtering.
- </para>
- </listitem>
- <listitem>
- <para>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
cFormatTags contains the number of tags support
by the driver for conversions.
- </para>
- </listitem>
- <listitem>
- <para>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
fdwSupport (the same as the one returned from
acmDriverDetails).
- </para>
- </listitem>
- </itemizedlist>
- </para>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
- <para>
+ <para>
The cFilterTags, cFormatTags, fdwSupport are the same
values as the ones returned from acmDriverDetails
function.
- </para>
- </sect2>
- </sect1>
-
+ </para>
+ </sect2>
+ </sect1>
</chapter>
More information about the wine-patches
mailing list