From Mike Hearn's winecfg post:
- Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab.
Still needs to be done. Not all that hard.
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. -- James Hawkins
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+
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(a)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
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(a)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(a)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
James Hawkins a écrit :
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. yes (I'd rather put a ref to sound or MM in the driver name)
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. yes. Note that you cannot use WaveOutOpen (for example) for opening the driver, but LoadDriver (as winmm does). Would the registry value for audio driver be wineautodetect instead of winealsa, wineoss etc? yes If this is how it is to be implemented, nothing in winmm would have to be changed would it? correct That's what I'm thinking. Are alsa, oss, arts etc the wave out part of winmm? they are more than that. they also implement wave in, midi, mixer type of interface... You need to proxy all of that.
A+
they are more than that. they also implement wave in, midi, mixer type of interface... You need to proxy all of that.
Ok, well I think I have enough information to start churning out this driver. Does the name winemmautodetect work? On Fri, 01 Oct 2004 23:24:13 +0200, Eric Pouech <pouech-eric(a)wanadoo.fr> wrote:
James Hawkins a écrit :
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. yes (I'd rather put a ref to sound or MM in the driver name)
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. yes. Note that you cannot use WaveOutOpen (for example) for opening the driver, but LoadDriver (as winmm does). Would the registry value for audio driver be wineautodetect instead of winealsa, wineoss etc? yes If this is how it is to be implemented, nothing in winmm would have to be changed would it? correct That's what I'm thinking. Are alsa, oss, arts etc the wave out part of winmm? they are more than that. they also implement wave in, midi, mixer type of interface... You need to proxy all of that.
A+
-- James Hawkins
James Hawkins a écrit :
they are more than that. they also implement wave in, midi, mixer type of interface... You need to proxy all of that.
Ok, well I think I have enough information to start churning out this driver. Does the name winemmautodetect work? perhaps a bit long. What about winemmdetect ? A+
On Sun, 3 Oct 2004, Eric Pouech wrote:
James Hawkins a �crit :
they are more than that. they also implement wave in, midi, mixer type of interface... You need to proxy all of that.
Ok, well I think I have enough information to start churning out this driver. Does the name winemmautodetect work? perhaps a bit long. What about winemmdetect ?
I vote for winemmd, winemma or in most lengthy case - winemmauto. €.02
What about winemmdetect ? I vote for winemmd, winemma or in most lengthy case - winemmauto.
hehe what's it gonna be? On Sun, 3 Oct 2004 17:57:30 +0200 (EET), Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
On Sun, 3 Oct 2004, Eric Pouech wrote:
James Hawkins a �crit :
they are more than that. they also implement wave in, midi, mixer type of interface... You need to proxy all of that.
Ok, well I think I have enough information to start churning out this driver. Does the name winemmautodetect work? perhaps a bit long. What about winemmdetect ?
I vote for winemmd, winemma or in most lengthy case - winemmauto. €.02
-- James Hawkins
Hi, On Sun, Oct 03, 2004 at 11:11:56AM -0400, James Hawkins wrote:
What about winemmdetect ? I vote for winemmd, winemma or in most lengthy case - winemmauto.
hehe what's it gonna be? Who knows, but I vote for winemmauto or winemmdetect (or _ variants of those) or wineaudioauto etc. winemmd sounds much too non-descriptive too me.
Andreas Mohr
For now I'll use winemmdetect, and if we decide to change it later, then that's ok...I can change it. On Sun, 3 Oct 2004 18:00:54 +0200, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote:
Hi,
On Sun, Oct 03, 2004 at 11:11:56AM -0400, James Hawkins wrote:
What about winemmdetect ? I vote for winemmd, winemma or in most lengthy case - winemmauto.
hehe what's it gonna be? Who knows, but I vote for winemmauto or winemmdetect (or _ variants of those) or wineaudioauto etc. winemmd sounds much too non-descriptive too me.
Andreas Mohr
-- James Hawkins
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
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).
I don't think we want to add yet another driver just for autodetection. Each driver should simply refuse to load if its hardware isn't present, then winmm can load each of them in turn until one succeeds.
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.
Yes, we definitely want to move in that direction, the code duplication we have now is a real mess. -- Alexandre Julliard julliard(a)winehq.org
I don't think we want to add yet another driver just for autodetection. Each driver should simply refuse to load if its hardware isn't present, then winmm can load each of them in turn until one succeeds. you must then ensure that the list of drivers from the registry fits you desired order (e.g. Alsa before OSS, or ESD...). A+
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
I don't think we want to add yet another driver just for autodetection. Each driver should simply refuse to load if its hardware isn't present, then winmm can load each of them in turn until one succeeds. you must then ensure that the list of drivers from the registry fits you desired order (e.g. Alsa before OSS, or ESD...).
Yes exactly, this allows the user to specify which drivers to try and in what order. That's something we want to support anyway. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard a écrit :
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
I don't think we want to add yet another driver just for autodetection. Each driver should simply refuse to load if its hardware isn't present, then winmm can load each of them in turn until one succeeds.
you must then ensure that the list of drivers from the registry fits you desired order (e.g. Alsa before OSS, or ESD...).
Yes exactly, this allows the user to specify which drivers to try and in what order. That's something we want to support anyway.
but this needs to be done in a "portable" way... ie still using the registry settings which are in a "all that's listed" semantics, not a "first that works" semantics So, it would mean, for example, extending -potentially- each regular registry for a driver, into something which lists the possible drivers and stops the loading when the first one succeeds. A+
Alexandre Julliard wrote: [...]
I don't think we want to add yet another driver just for autodetection. Each driver should simply refuse to load if its hardware isn't present, then winmm can load each of them in turn until one succeeds.
Note that this pretty much works already. To try it out, edit your configuration file (yes I'm old fashioned, I still have a configuration file<g>) as follows: [WinMM] "Drivers" = "winearts.drv;winealsa.drv;wineoss.drv" Then on a system with no aRts and no Alsa, Wine will automatically load the wineoss driver. A system with aRts plus Alsa plus OSS emulation, will see devices for all three drivers, i.e. it should look as if we had three sound cards. We might want to change that so winmm stops as soon as it finds a driver that works but I'm not sure that would be better: we could conceivably have two sound cards, one accessible through Alsa and the other through OSS. What needs fixing is that: * winearts seems to be causing some problems with threading. * if more than one driver is loaded DirectSound tends to get confused * some drivers may still need fixing to return the correct value if the underlying sound system is not available (wineaudioio, winejack, winenas) Basically it all needs more testing and a bit of debugging. -- Francois Gouget fgouget(a)codeweavers.com
participants (6)
-
Alexandre Julliard -
Andreas Mohr -
Eric Pouech -
Francois Gouget -
James Hawkins -
Saulius Krasuckas