> 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
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
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
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 t
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 kic
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 <[EMAIL PROTE
