audio driver autodetection
pouech-eric at wanadoo.fr
Fri Oct 1 14:29:44 CDT 2004
> I remember working on this a couple months ago. I put the driver
> detection in winmm.c, but that was wrong. I can't remember exactly
> what I was supposed to do to fix it...something like put the driver
> detection in each driver. I'm not really sure what that means or how
> it would work if it does what I think it does. Does it mean that we
> load one driver, and if it doesn't detect its *nix counterpart then it
> loads the next driver? I would like to get to work on this task, so
> if anyone has any pointers or ideas on this one, please let me know.
there were at that point two different discussions, which may boil down,
someday, to the same thing:
1/ don't put driver detection in winmm. we want winmm to load drivers
from the registry settings, so that it can be shared between, say, Wine
and ReactOS. Each "OS" then decides how it's going to manage its
drivers. Instead, for Wine, use a specific driver which will detect
which hardware is present and then load the appropriate driver (and pass
every message to it).
2/ most of current wine audio drivers look very similar and share a
great deal of code. It may be interesting to only make a unique audio
driver which is going to pickup the decent hardware interface in the
Note: that doing 1/ is still compatible with current drivers. You keep
them as they are. By default, wine will get a unique driver (the proxy
as described above). For power users, you can still configure the
registry and install the "physical" driver you want to use (and be
better performance wise).
If you want to get a glimpse at what a proxy driver should be, look
inside dlls/winmm/wavemap (except for the driver loading, where you'll
need to do it "by hand", as winmm does).
More information about the wine-devel