Re: RFC: winedev guide multimedia chapter patch

[Andrew Eikum]

Looks good for the most part. Some thoughts below...

On Sat, Aug 17, 2013 at 01:25:00PM +0200, Frédéric Delanoy wrote:
> -
>  The implementation can be found in a number of directories:
> -
>  <itemizedlist>
> -
>    <listitem>
> -
>      <para>
> -
>        <filename class="directory">dlls/winmm/</filename>, <filename
> -
>        class="directory">dlls/mmsystem.dll16/</filename> and <filename
> -
>        class="directory">dlls/msacm32.drv/</filename>
> -
>      </para>
> -
>    </listitem>
> -
>    <listitem>
> -
>      <para>
> -
>        <filename class="directory">dlls/msacm32/</filename> and <filename
> -
>        class="directory">dlls/msacm.dll16/</filename> (for the audio compression/decompression
> -
>        manager)
> -
>      </para>
> -
>    </listitem>
> -
>    <listitem>
> -
>      <para>
> -
>        <filename class="directory">dlls/msvfw32/</filename> and <filename
> -
>        class="directory">dlls/msvideo.dll16/</filename> (for the video
> -
>        compression/decompression manager).
> -
>      </para>
> -
>    </listitem>
> -
>  </itemizedlist>

Most of these paths are not very relevant. The 16-bit DLLs are really
just wrappers around the full DLLs to convert into 16-bit types.

I would list, in order of importance, mmdevapi, dsound, winmm,
msacm32, and msvfw32.

The first three are the main audio APIs.  dsound and winmm are
implemented on top of mmdevapi, and that is implemented in the three
driver DLLs, winealsa.drv, winecoreaudio.drv, and wineoss.drv

msacm32 deals with converting between audio formats, and msvfw32 deals
with displaying videos. Both of those use external DLLs like mciavi32,
or even DLLs supplied by applications, to do conversions.
> -
>    The low level layer has also some helper DLLs (like the msacm32/msacm.dll16
> -
>    and msvfw32/msvideo.dll16 pairs).

Again, I wouldn't bother listing the 16-bit DLLs at all, through the
whole patch. They aren't interesting.
> @@ -486,7 +502,7 @@ Kernel space |                    Client applications
>      Note that a Wine specific flag has been added to the
>      <function>wodOpen</function> 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
> -
>      winmm wave output device. This should be changed in the
> future.
>
>  </para>

This whole paragraph can actually be removed. The dsound object it
refers to no longer exists.

Thanks for updating this,
Andrew