Eric Pouech wrote:
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+
It is not typical for an application to bypass winmm and communicate
directly with a driver. Only a control panel or device manager type
application would ever even try something like this. Winecfg is one of
those unusual programs. Opening a driver more than once will not cause
any problems. The open functions in all the drivers are just stubs.
Loading a driver is what causes a drivers state to be initialized and
there is no way going through winmm to load the same driver more than
once. Trying to open a specific driver's device through for example
waveOutOpen more than once either through winmm or directly to the
driver will only allow the first open to succeed because all attempts
after the first will see that the device is already opened and fail.
- Re: Robert Reif : winecfg: Added support for auto detecting al... Robert Reif
-
