ALSA implementation

[Jan Zerebecki]

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