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

[Robert Reif]

Robert Reif wrote:
> 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.
>
>
I forgot to mention that this was with multiple wine applications.  I
don't recall ever trying from within the same app.  That's the problem
with some games that open the sound card to play the intro and then
open it again to play game sounds.  This type of behavior would
also fail on Windows 95 or first release Windows 98 if the underlying
hardware device didn't support multiple opens.  The wine audio
model is patterned after the Windows 95 model so the underlying
audio API must support multiple opens of the same device for wine
to also support it.