Wine Tasklist

Gavriel State gav at transgaming.com
Mon Dec 31 11:37:01 CST 2001


eric pouech wrote:
> 
> >  * Native Alsa support
> >    - Could it offer capabilities that OSS does not offer?
> [snip]
> >    - Anti-rational: Alsa includes an OSS compatibilty mode that seems to
> >      work pretty well
> ALSA is needed when you need proper full duplex capabilities
> however, only ALSA 1.0 should be supported (0.5 and 0.9 shouldn't,
> except
> if 0.9 interface turns out to stay the one for 1.0)

One of the most annoying problems we've seen with Alsa OSS emulation 
is that it doesn't properly support directly mmap-ing the sound buffer.
It kind of claims to do it, but on most of the machines we've tried
alsa on, actually doing the mmap fails.  

This means that to build a single Wine binary that supports doing 
dsound on most different hardware, we have to disable direct sound
buffer access, and use the dsound HEL mode instead.  This, in turn,
results in either latency problems, or cracking, depending on how
we tune dsound, even on OSS systems.  And problems are magnified 
on ALSA cards, since the driver is doing yet another layer of 
conversion before sending the data out to the sound chip.

The TransGaming subscribers have voted for us to do something to 
fix this.  I'd like to put one of our people on it, but we can't
spare them right now from their DX8 tasks.  So: we are willing to 
sponsor the development of an ALSA back-end sound driver for Wine, 
if anyone is willing to work on it.  If you're interested in doing
the work, let me know and we can discuss details.

> >  * Winedbg g++ 3.0 support
> >    - The debugging format and the ABI changed in g++ 3.0 and winedbg
> >      does not support the new ABI.
> >    - This prevents debugging of C++ Winelib applications
> >    - This is especially troublesome for MFC Winelib applications

Why would you want to use Winedbg for a Winelib application, instead 
of gdb?  

> some other items to look at:
> * make the server a linux kernel module (has been discontinued) but
> could
> provide some performance enhancements

We did some more examination of this question, and came up with some
notes and code for doing a server-accellerator kernel module that
would move some functionality into the kernel, but keep the current
architecture mostly intact.  If I recall, the architecture centered
around the creation of a /proc like virtual file-system for managing 
NT kernel objects.  Our own resources for continuing this effort 
directly are limited, but again, we would consider sponsoring 
further development along these lines: WineServer overhead is one 
of the nastier performance blocks for several games we've looked at.  

I'll try to see if we can put the notes and code we've done so far
into better shape to be picked up by someone else.

 -Gav

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com




More information about the wine-devel mailing list