Re: [Bug 19523] winmm: Multiple waveOutOpen calls on single device supported by Windows, not Wine
Taking this conversation out of the bug, since it seems I opened the bug in error and it should be closed.
On Sep 19, 2009, at 2:29 AM, wine-bugs@winehq.org wrote:
http://bugs.winehq.org/show_bug.cgi?id=19523
--- Comment #3 from Eric Pouech eric.pouech@orange.fr 2009-09-19 02:28:51 --- of course, there is...
OK, in that case: a) that's good to know; and b) thanks for setting me straight. I might quibble with "of course", though. ;)
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?
but, none of the wine drivers correctly initialize the dwUser while processing the various XXXX_OPEN messages
Does that mean this functionality is untested?
Thanks again, Ken
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+
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.
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.
-
Eric Pouech -
Ken Thomases -
Robert Reif