On Wed, Sep 20, 2006 at 05:55:03PM +0200, Marcus Meissner wrote:
On Wed, Sep 20, 2006 at 05:54:06PM +0200, Tomas Carnecky wrote:
Jan Zerebecki wrote:
As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected.
Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread?
It is because how (all) signals work and how wine works. The fd method may not require a separate thread when we can combine the event loop of the currently used sound thread with e.g. the select for the alsa-lib fd(s), thu I didn't look at that and it might not be possible.
Yes, we cannot execute code in signals, namely critical sections cannot be entered recursively from a signal handler.
Blocking the signal was not accepted by Alexandre, so we would need to use something else ;)
I later noticed that the signal blocking patch also didn't work as expected (for e.g. War3 I got many buffer underruns) because it seemed to use much cpu (so It might have only mitigated the race condition...).
Also as I understood from what AJ said, the issue is more complex. He mentioned that it would be possible to make it work, but we agreed that when there is an easier and more straight forward solution it should be preferred. (Another problem I remember is that the sigaction callback can trigger in any thread which seems to be something we realy want to avoid.)
Jan