Wine PulseAudio Driver

[Arthur Taylor]

> 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:
> 1.  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.

> 2.  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
-- 
Arthur Taylor <theycallhimart at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winepulse-0.5.patch
Type: text/x-patch
Size: 108091 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20081001/3ada4f0f/attachment-0001.bin