[Bug 19523] winmm: Multiple waveOutOpen calls on single device supported by Windows, not Wine

Robert Reif reif at earthlink.net
Sat Sep 19 07:48:48 CDT 2009


Eric Pouech wrote:
>
>>> let's take the wave out driver interface as example:
>>>
>>> DWORD WINAPI wodMessage(UINT wDevID, UINT wMsg, DWORD_PTR dwUser,
>>>                        DWORD_PTR dwParam1, DWORD_PTR dwParam2);
>>>
>>> in case wMsg in WODM_OPEN, dwUser is expected to be a pointer to a 
>>> DWORD, that
>>> the driver is supposed to filled with a unique instance ID (to 
>>> identify the
>>> stream)
>>>
>>> in other (subsequent) messages, winmm passes in dwUser the unique ID 
>>> defined by
>>> the driver at WODM_OPEN time
>>>
>>> winmm correctly supports this scheme (see MMDRV_Open in 
>>> dlls/winmm/lolvldrv.c)
>>
>> No offense, but looking at MMDRV_Open, it's clear as mud to me that 
>> dwDriverInstance has this meaning and corresponds to dwUser.  Is 
>> there any documentation of the low-level driver interface?
> google for "Windows NT DDK - Multimedia Drivers.pdf"
> or http://www.osronline.com/ddkx/w98ddk/mmedia_4otx.htm
> from the later
>
> DWORD /dwUser/
>    For the *WODM_OPEN* message, the driver should fill this location
>    with its instance data. For any other messages, the instance data is
>    returned to the driver. Drivers supporting multiple clients can use
>    this instance data to keep track of which client is associated with
>    the message.
> the former has way more details on the message processing though
>>
>>
>>> but, none of the wine drivers correctly initialize the dwUser while 
>>> processing
>>> the various XXXX_OPEN messages
>>
>> Does that mean this functionality is untested?
>>
> IIRC I tested it a century ago with the native wave mapper (for 16 and 
> 32 versions of it)
> A+
>
IIRC when I was doing wine audio many years ago on Red Hat 9 with
real OSS (2.4 kernel) and a Sound Blaster Live! sound card with real
multiple hardware buffer support and OSS multiple open support, I
was successfully able to open and use the same device multiple times.

I haven't tried it but I assume ALSA OSS emulation is not capable of
opening the same device multiple times, even if the hardware supports it?

The same is probably true for ALSA native also? Wasn't dmix developed
to do this?

If the hardware supports multiple open and/or the audio API supports it,
wine should be able to open the same device multiple times even with
different sample rates and number of channels.




More information about the wine-devel mailing list