Re: [ros-kernel] Weekend Coder Project: WinMM functions
Well our WinMM is totally wrong but I dont know how much help the WINE winmm will be as there are a LOT of functions it imports that are 9x only. Wines Winmm.dll needs to be rewritten if we are to use it properly. Eric Pouech can you comment? Thanks Steven --- Robert Dickenson <odin(a)pnc.com.au> wrote:
G'day to all on the list,
I have no idea of the quality of the content however our branch of the wine source has a rather large implementation of winmm.dll which currently builds fine. I have never tried testing any of it however.
BTW: I'm not back yet.
Best wishes to everybody, RobD.
The accumulated lore surrounding the numerical value pi () is an example of our species' continuing tendency to try to force our irrational notions on an otherwise completely rational universe.
At 01:51 PM 17/02/2003 -0800, you wrote:
Hi
While trying to run java.exe, it fails to find function timeBeginPeriod (jvm.dll). Using dependency walker, I see that timeBeginPeriod, timeEndPeriod and timeGetTime are required from WinMM.
We have a basically empty (except for stubs) WinMM in reactos/lib/winmm. Does anyone (read: weekend coder) want to take on the task of writing these functions? WINE could be a help.
Cheers Jason __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
__________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
Steven Edwards wrote:
Well our WinMM is totally wrong but I dont know how much help the WINE winmm will be as there are a LOT of functions it imports that are 9x only. Wines Winmm.dll needs to be rewritten if we are to use it properly.
Eric Pouech can you comment?
some time ago I tried to kick out of winmm most of 9x-ism so that it would be easier to port the DLL to some other OS (read ReactOS) if you get the files marked as 16bit out of the build you should be fine the time* function should work out of the box, except you'll sure want to implement a more precise timing engine (current time* implementation is based on an internal thread, which of course isn't very accurate) you'll have also for the rest of winmm to implement the wdmaud.drv which isn't implemented in wine because of no use (we use in fact .drv to map to existing audio interfaces: OSS, ALSA, aRts, Jack...) feel free to ask for more info A+ -- Eric Pouech
could a wineesd.drv be written ? has someone started such a project ?
you'll have also for the rest of winmm to implement the wdmaud.drv which isn't implemented in wine because of no use (we use in fact .drv to map to existing audio interfaces: OSS, ALSA, aRts, Jack...)
feel free to ask for more info A+
-- Eric Pouech
===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Well, I'd imagine there's no wineesd because eSound sucks straws. Jack is a much better sound server, and I know at some point (probably soon) GNOME is going drop eSound entirely, they're just waiting for the move to gstreamer to be completed, so hopefully soon eSound will die the death it deserves. Ideally both KDE and GNOME would use Jack, it might be something to raise on the xdg-list On Tue, 2003-02-18 at 19:43, Sylvain Petreolle wrote:
could a wineesd.drv be written ? has someone started such a project ?
you'll have also for the rest of winmm to implement the wdmaud.drv which isn't implemented in wine because of no use (we use in fact .drv to map to existing audio interfaces: OSS, ALSA, aRts, Jack...)
feel free to ask for more info A+
-- Eric Pouech
===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
On Wednesday 19 February 2003 04:17 am, Mike Hearn wrote:
Well, I'd imagine there's no wineesd because eSound sucks straws. Jack is a much better sound server, and I know at some point (probably soon) GNOME is going drop eSound entirely, they're just waiting for the move to gstreamer to be completed, so hopefully soon eSound will die the death it deserves.
Ideally both KDE and GNOME would use Jack, it might be something to raise on the xdg-list
I also think that a move to jack would be best, even for general purpose non-audio apps. I've tried (unsuccessfully thus far) to get jack to include a blocking io api that could be used to make it easy for existing apps to be ported. My thought was that most general purpose apps wouldn't mind using jack but don't need to jump through any hoops if they don't need extremely low latencies and stream synchronization. Why rewrite your whole app if it only uses audio when a dialog box pops up or new mail arrives? The api in its working but unfinished form is at http://www.sf.net/projects/bio2jack if anyone is interested. It is basically the wine jack implementation as a backend and it works quite well for xmms.
On Tue, 2003-02-18 at 19:43, Sylvain Petreolle wrote:
could a wineesd.drv be written ? has someone started such a project ?
I would imagine it would be pretty straight forward to write an esd drive for wine. If someone wants to do this and needs some help feel free to email me. Thanks, Chris
I also think that a move to jack would be best, even for general purpose non-audio apps. I've tried (unsuccessfully thus far) to get jack to include a blocking io api that could be used to make it easy for existing apps to be ported. My thought was that most general purpose apps wouldn't mind using jack but don't need to jump through any hoops if they don't need extremely low latencies and stream synchronization. Why rewrite your whole app if it only uses audio when a dialog box pops up or new mail arrives? The api in its working but unfinished form is at http://www.sf.net/projects/bio2jack if anyone is interested. It is basically the wine jack implementation as a backend and it works quite well for xmms.
That's good to hear! One thing I've just thought of is whether for replicating the windows multimedia system (codecs etc) using gstreamer might not be quite appropriate - at least for DirectShow. I don't really know how much Wine has in this respect though.
-- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
participants (5)
-
Chris Morgan -
Eric Pouech -
Mike Hearn -
Steven Edwards -
Sylvain Petreolle