> The Istuff is straightforward and should probably be added to the
> winmm drivers, no problem... the question is how we should let DirectSound
> contact the winmm drivers to get the interface in the first
> place in Wine, since it seems rather kludgy to implement that VxD
> interface, considering that loading libdsound.so should preferably be
> optional.
>
> Of course, I can easily think up a few possible ways myself, but I'd
> rather hear what the design/multimedia authorities (Eric?) have to say
> first...
well there are least two issues to look at:
1/ how to get (load) the correct module
2/ how to grab the DsDriver from this module
on 1/
as of today, low level drivers are hard coded in winmm (which is baaaad)
they should be loaded from registry keys (still has to be done)
so, it can be rather straightforward to use the same mechanism for
dsound as for winmm => for now, hard code the name of DLL.
when proper registry diving is done for winmm, port it to dsound; then
enumerate thru drivers and grab the one(s) of interest (of course,
registry diving can be first written for dsound, then ported to winmm ;-)
on 2/
I don't have any definitive answers. two possibilities:
- since every lowlevel driver is a driver (in MS terminology), it has
a specific entrypoint called DriverProc used for message oriented
communication. Wine could use a specific (wine only) message to get
the IDsDriver iface
- we could use a specific (wine only) entrypoint to that DLL (a driver
is also a DLL). Since, that's also the way MS gets the wave
(wodMessage/widMessage), midi, mixer features from a low level MM driver,
it sounds reasonable to do the same
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
