audio driver autodetection

[James Hawkins]

I want to make sure I'm getting the right idea.  So I would implement
a new audio driver like winealsa, wineoss etc but named something like
wineautodetect.  This driver is actually a proxy that checks each of
the available drivers to see if they are available, and if so,
initialize that driver and send all audio messages to the it.  Would
the registry value for audio driver be wineautodetect instead of
winealsa, wineoss etc?  If this is how it is to be implemented,
nothing in winmm would have to be changed would it?  That's what I'm
thinking.  Are alsa, oss, arts etc the wave out part of winmm?  So
winmm makes calls to the wineautodetect driver like it would any other
driver, and then wineautodetect in turn passes those calls onto the
detected driver, right?  Ok that's about what I have right now.  Let
me know if you have any thought, ideas, or suggestions.


On Fri, 1 Oct 2004 15:40:54 -0400, James Hawkins <truiken at gmail.com> wrote:
> > If you want to get a glimpse at what a proxy driver should be, look
> > inside dlls/winmm/wavemap
> 
> Ok, thanks Eric.  I'll take a look at what we have and see if I can
> come up with something useful.
> 
> 
> 
> On Fri, 01 Oct 2004 21:29:44 +0200, Eric Pouech <pouech-eric at wanadoo.fr> wrote:
> > > 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
> > underlying OS.
> >
> > 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).
> >
> > HTH
> > A+
> >
> 
> 
> --
> James Hawkins
> 



-- 
James Hawkins