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. 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.
Jack and esound are fundamentally flawed because they create 10 virtual sound cards that all reference a single physical device. This doesn't take into account multiple devices. The proper way to implement this is to allow multiple opens of the same device (just like windows). That way two or more programs can open one card and other programs can open another card and none of the programs are aware or even care about the others. I have multiple sound cards and headsets in a single computer for music and VoIP and I need a way for individual programs to work with specific devices (just like in windows).
we do agree here that jack & esound (like any interface with integrated audio mixer) should be multiple instance drivers and not single instance ones.
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).