On Thu, 17 Mar 2005, Robert Reif wrote:
Fall back to default header prepare and unprepare functions.
A driver only needs to support prepare and unprepare functions when it is doing something special like allocating a DMA buffer for each header. Since we don't do anything special, just fall back to the default functions. Removes redundant code.
Does that mean we could do the same wor winealsa, winearts, etc?
Francois Gouget wrote:
On Thu, 17 Mar 2005, Robert Reif wrote:
Fall back to default header prepare and unprepare functions.
A driver only needs to support prepare and unprepare functions when it is doing something special like allocating a DMA buffer for each header. Since we don't do anything special, just fall back to the default functions. Removes redundant code.
Does that mean we could do the same wor winealsa, winearts, etc?
Yes, I am going to do winealsa next now that I have an alsa system. I haven't really looked at the others yet but will do them if someone doesn't beat me to it ;-)
On Fri, 18 Mar 2005, Robert Reif wrote: [...]
Does that mean we could do the same wor winealsa, winearts, etc?
Yes, I am going to do winealsa next now that I have an alsa system. I haven't really looked at the others yet but will do them if someone doesn't beat me to it ;-)
Cool. I think I'll let you win<g>.
I have been thinking about how to share more more code between the drivers. My understanding is that we cannot modify the winmm-driver protocol because we have to conform to the standard Windows API, mostly so that winmm can be reused with as little modifications as possible by the ReactOS project.
Steven mentionned another route which would be to implement mmdrv and shift our drivers to hook to mmdrv instead of winmm (that's a very rough explanation but Steven will fill in the gaps if necessary). But again I believe the API is going to constrain us so I don't think we will be able to share more code.
So here's another idea (which may be stupid but I have to air it on the off chance it's not completely braindead).
The only thing that ReactOS or other projects can reuse is winmm, the sound drivers themselves (wineoss, winealsa, etc) are too Unix specific so that they will only work in Wine anyway. So a way to share code between the drivers would be to put it in another dll and then have these drivers link with it. But adding an extra dll is always annoying / ugly and I am assuming this is why it has not been done already.
So here's a variant on this theme: why no export Wine-only APIs from winmm and have the drivers call these.
* For instance winmm could implement and export the wine_bytes_to_mmtime() function which given the proper parameters should be driver-independent so that we could remove its implementation from each driver.
* The drivers already link to winmm so calling these Wine-only APIs would be no problem.
* We could implement these APIs in a separate C file, wine.c, so that disabling them in other projects would simply be a matter of removing wine.c from the Makefile.
* This introduces a dependency of the drivers on the Wine project but that's not a problem if they're not reusable anyway.
Now maybe I'm mis-evaluating the amount of code that could be shared beyond this wine_bytes_to_mmtime() function and this is not worth it. Does anyone have a more informed opinion on the matter?
Now maybe I'm mis-evaluating the amount of code that could be shared beyond this wine_bytes_to_mmtime() function and this is not worth it. Does anyone have a more informed opinion on the matter?
the better way would be to merge all wine MM drivers into a single one. This would solve most of the code sharing, but also share most of the pure driver stuff (which is rather redundant across all drivers) as well as bit stream handling. And it would incidentally solve some loading and discovery of existing interfaces in the underlying kernel
A+
Francois Gouget wrote:
I have been thinking about how to share more more code between the drivers. My understanding is that we cannot modify the winmm-driver protocol because we have to conform to the standard Windows API, mostly so that winmm can be reused with as little modifications as possible by the ReactOS project.
What would be cool is to implement a real driver that you can access using CreateFile and DeviceIoControl. Then the wave api could use mmdrv.dll to translate the calls to the device and dsound.dll could use the kernel streaming interfaces to access the drivers directly. ReactOS would be happy but it's probably too much work for wine.
-
Eric Pouech -
Francois Gouget -
Robert Reif