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