Robert Reif wrote:
Eric Pouech wrote:
We never "load" a driver more than once. Winecfg calls winmm
OpenDriver which will only ever load a single instance of the driver
into memory. Subsequent OpenDriver calls will reference the existing
in memory driver. Wine models the single instance device driver that
supports multiple physical devices.
what you end up with is a situation where:
- two calls to OpenDriver for the same driver will provide:
+ a separate HDRVR (one for each call)
+ the same driver ID at the driver level
+ an implementation at the driver level with a single data state
shared across the two HDRVR instance
This is true and is also how windows works with the tests I have done
with a user installable driver. The reason this works is because I am
only accessing the static driver configuration (GetNumDevs and
GetDevCaps). I have no intention of actually using the drivers for
anything else because they are not designed for that.
Here again, I'm not saying you *will* badly use the drivers (and your
current code doesn't). But, the way you changed things can let someone
do it (or a windows app), and we have no protection for that.
> I am opening the
driver, not the individual devices (WaveIn, WaveOut, ...). I agree that
under normal circumstances, bypassing winmm and accessing the driver
directly is the wrong thing to do because winmm is responsible for
coordinating things, but in this case and only this case (accessing
static driver configuration) it is OK.
The real way to do this would be
to have each driver register itself with the PnP manager and then we
could interface with it. I am using winmm (OpenDriver) for loading and
configuring the drivers which is perfectly legal to do. Only using
LoadLibrary and xxxMessage to get the number of devices and their
capabilities is the thing that is really questionable. A PnP manager
would fix that in the long term.
My concern here is that your changes require a driver to be opened (thru
OpenDriver) twice (one time by winecfg, a second time at winmm startup).
IMO, the target should be to implement the audio configuration in
winecfg without requiring to open twice a driver. It's likely to boil
down to let winmm do the core job.
I guess I have a terminology misunderstanding here and should probably
reread my driver documentation. I would like to see this class of
driver implemented so that only a single device shows up for a physical
device (multi channel cards being the exception). Each wave device
could be opened more than once. Each open would dynamically open a
connection to the mixing server. In this case with a single physical
sound card, waveOutGetNumDevs will always return 1 and a waveOutOpen
will always succeed (within mixer server limitations). This is how
windows works on versions that have kmixer (98SE up).
yup. this is also the way to go for a unified wine audio driver by the way.
A+
--
Eric Pouech
