Um.. I still don't see the patch? Sorry, but I'm too lazy to get it myself. Could you send it here?
Attached is a newer copy from the one currently in bugzilla. I'm still not sure of the proper procedure for doing things as this is probably my largest contribution yet. (Set the driver using the registry, winecfg patch is separate.)
Also, just to warn you: some people disagree that a PulseAudio driver is a good idea. Even if you write a good one, it might have to live out of tree. The usual arguments are:
- Drivers can bitrot (and have in the past), and having 6 poorly
implemented audio drivers is clearly worse than having one good one, even if that one is using a deprecated API and doesn't work nicely with other apps.
I've noticed a lot of hostility toward pulseaudio in general ;-) My thought is that if x11 was thrust on people today everyone would hate it too, but that isn't a good comparison as x11 is ancient by comparison and de-facto.
- We ought to be able to use PulseAudio's ALSA emulation. If that
doesn't work, then either our ALSA driver should be fixed, or PulseAudio's ALSA interface should be fixed.
IMHO this is a situation were it makes more sense to use pulse's native API over going through ALSA's, as we aren't just trying to join ALSA-pulse, we are trying to join WaveOut-ALSA-pulse (or even dsound on top of waveout.) Currently I can match the alsa driver's perceptive quality (buzz word) on my system using this code, dsound games and all. Mind you, my sound hardware is nothing to write home about. By far beats the current ALSA-pulse or ESD solutions.
I have no particular opinion and whether this gets accepted isn't up to me. I'm just reiterating what's been said about audio drivers in the past. So, please don't attempt to persuade me, as it won't make any difference ;-) --Juan
To wine developers: would it be useful to review dlls/winmm? Currently all mm-drivers (aux, mid, mod, wid, wod) functions are called using MDRV_Message calls. The arguments of a MDRV_Message are the device id (an array index), the message identifier, dwUser as the driver instance, and two parameters that depend upon the message. The driver instance DWORD seems useless to me, and it's value, while consistent, looks uninitialized (on my system is either 57 if I enable tracing, or random crazy large for a pointer if not.) My problem is that WaveIn / WaveOut devices are supposed to be able to support multiple streams if the hardware allows it, however it is impossible to support this currently as all MDRV_Message gives us is the device id the message is for (the only arguments to a WODM_PAUSE is the device id for instance.) This makes multiple streams impossible and therefor waveout drivers only support one stream per device. wineesd.drv gets around this by staticly making 10 waveout and 10 wavein devices, all effectively the same. If MDRV_Message were to pass in dwUser the device opening instance handle which winmm creates and apps use for the wave{out,in}* calls it would be possible to support multiple streams per device, and devices could represent hardware 1:1 like they are supposed to. So my questions are this: would changing the value of dwUser to the device instance handle be a good idea, and do any current mm-drivers depend upon dwUser being the seemingly uninitialized driver instance value?
Thanks