Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

[Robert Reif]

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).