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.