ALSA implementation

Jan Zerebecki jan.wine at zerebecki.de
Tue Sep 12 15:56:45 CDT 2006


On Fri, Sep 08, 2006 at 04:43:18PM -0400, Aaron Slunt wrote:
> I talked on #winehq in irc about how horribly alsa is implemented right 
> now. I was told that winmm would need a complete re-write and the dsound 
> needs some changes as well.

The alsa specific problems should be fixeable without touching
the rest of winmm or dsound. They each have problems, but not
directly related ones. In fact one of those bugs is realy
grave.

See bug #4093 : deadlock in alsa driver: CriticalSection WINEALSA_mmap_crst
http://bugs.winehq.org/show_bug.cgi?id=4093

There is another "bug" in winealsa that leads to changing the
size of the mmap-buffer (that makes a test in dsound fail) and at
a first go I didn't find the proper function in alsa to set the
buffer size. I didn't look further into this as it's pretty easy
to set a buffer size with alsa dmix. (The buffer size needs to be
a multiple of any sample size we will use, so that we don't need
to change the size to avoid a remainder. Thas is because we can't
have fractions of samples and the buffer is looped over so just
not using part of it does not work either.)

> My question is: anybody here who's familiar with all of the changes that 
> need to be made to get alsa working properly?

To fix bug #4093 we need to replace the currently used signal
callback method (very complex to make signals work properly [in
Wine], thus we should avoid it) with I guess a fd based method
for example with select. The alsa-api documentation about this
looks pretty usable.

There are still frequent other problems with sound (especialy
with dsound), but together with something like
"SetThreadPriority" I found most sound is quite ok.
http://wiki.winehq.org/SetThreadPriority


Jan




More information about the wine-devel mailing list